3 ms·

It is necessary - you cannot reconstruct your function prototypes from the IR declarations. That's why, for example, SPIR provides signedness information in the

by sklogic 12y ago

It is necessary - you cannot reconstruct your function prototypes from the IR declarations. That's why, for example, SPIR provides signedness information in the metadata. This ugly hack would not be necessary if IR had explicitly signed types.

DannyBee 12y ago
"It is necessary - you cannot reconstruct your function prototypes from the IR declarations. " Why would you want to do this? You are trying to reconstruct high level, language specific info from low level, language independent info. Of course you can't do this. Your comment comes out to "lowering loses information", which is, of course, true. So let's try again: What semantic information do you believe is lost here. IE where does it result in an incorrect translation, or the inability to optimize something? Because that's what "necessary" would come out to.
- sklogic 12y ago
  > Why would you want to do this? Because SPIR requires that you can load and enqueue an OpenCL kernel from an IR, without having a source. And you need this type information in order to be able to format your arguments properly. Please note that I'm not commenting here on the very choice of LLVM IR as a common medium made by SPIR committee. > Your comment comes out to "lowering loses information", which is, of course, true. Exactly. But the current common uses of LLVM IR do require some of the information which is lost, and, in case of signedness, it was not even necessary to lower it. > IE where does it result in an incorrect translation, or the inability to optimize something? You're limiting IR uses to translation and optimisations. Fine. I would have welcomed this way of thinking. But, unfortunately, this is not the case.
  - DannyBee 12y ago
    " But the current common uses of LLVM IR" Portability of a high level language is an explicit non-goal of LLVM :) The fact that someone decided to do it just makes them silly :)
    - sklogic 12y ago
      I know it's silly. I can go on forever on what I think about SPIR and RenderScript. But, unfortunately, now it's a fact, an objective reality we have to deal with.

by sklogic 12y ago

DannyBee 12y ago

"It is necessary - you cannot reconstruct your function prototypes from the IR declarations. " Why would you want to do this? You are trying to reconstruct high level, language specific info from low level, language independent info. Of course you can't do this. Your comment comes out to "lowering loses information", which is, of course, true. So let's try again: What semantic information do you believe is lost here. IE where does it result in an incorrect translation, or the inability to optimize something? Because that's what "necessary" would come out to.

sklogic 12y ago
> Why would you want to do this? Because SPIR requires that you can load and enqueue an OpenCL kernel from an IR, without having a source. And you need this type information in order to be able to format your arguments properly. Please note that I'm not commenting here on the very choice of LLVM IR as a common medium made by SPIR committee. > Your comment comes out to "lowering loses information", which is, of course, true. Exactly. But the current common uses of LLVM IR do require some of the information which is lost, and, in case of signedness, it was not even necessary to lower it. > IE where does it result in an incorrect translation, or the inability to optimize something? You're limiting IR uses to translation and optimisations. Fine. I would have welcomed this way of thinking. But, unfortunately, this is not the case.
- DannyBee 12y ago
  " But the current common uses of LLVM IR" Portability of a high level language is an explicit non-goal of LLVM :) The fact that someone decided to do it just makes them silly :)
  - sklogic 12y ago
    I know it's silly. I can go on forever on what I think about SPIR and RenderScript. But, unfortunately, now it's a fact, an objective reality we have to deal with.