In looking at the LLVM reference manual, it is conspicuous that (a) the IR does not define condition codes, and (b) the IR does not define opcodes that return condition results in addition to their computational results. Given the IR as it stands, how does one go about *efficiently* implementing a language that requires checked arithmetic? I do understand that it can be done using intrinsics, but that implementation is (to put it mildly) suboptimal. For integer ops, I really want to be able to get at the carry/overflow bit. For floating point ops, I really want to be able to get out the floating point NaN state in order to exploit the NaN propagation features provided by some hardware. I'm sure this has been considered, but no means for dealing with this sort of thing is jumping out at me from looking at the IR spec. What am I missing? Note: I can see at least two ways to deal with this by extending the IR, but I would like to understand the current intentions first. shap
On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote:> In looking at the LLVM reference manual, it is conspicuous that (a) > the > IR does not define condition codes, and (b) the IR does not define > opcodes that return condition results in addition to their > computational > results.We currently don't have this because noone has implemented it yet. It would be great to have this.> Given the IR as it stands, how does one go about *efficiently* > implementing a language that requires checked arithmetic? I do > understand that it can be done using intrinsics, but that > implementation > is (to put it mildly) suboptimal.Why? -Chris
On Tue, 2008-03-25 at 21:18 -0700, Chris Lattner wrote:> > Given the IR as it stands, how does one go about *efficiently* > > implementing a language that requires checked arithmetic? I do > > understand that it can be done using intrinsics, but that > > implementation > > is (to put it mildly) suboptimal. > > Why?Hmm. Perhaps I shouldn't have written so quickly. My assumption was that intrinsics would likely entail a procedure call. More later -- my three year old just woke up. shap
On Tue, 2008-03-25 at 21:18 -0700, Chris Lattner wrote:> On Mar 25, 2008, at 8:25 PM, Jonathan S. Shapiro wrote: > > > In looking at the LLVM reference manual, it is conspicuous that (a) > > the > > IR does not define condition codes, and (b) the IR does not define > > opcodes that return condition results in addition to their > > computational > > results. > > We currently don't have this because noone has implemented it yet. It > would be great to have this.I want to background process this for a bit, but it would be helpful to discuss some approaches first. There would appear to be three approaches: 1. Introduce a CC register class into the IR. This seems to be a fairly major overhaul. 2. Introduce a set of scalar and fp computation quasi-instructions that accept the same arguments as their computational counterparts, but produce *only* the condition code. For example: add i32 ... produces result add_cc i32 ... produces condition codes Once this exists, re-combine the instructions in the back end with peepholes. 3. Handle CC as a black magic special case, which at least has the merit of tradition. :-) Given the number of different ways that different bits of hardware handle CCs, I am inclined to think that the right approach, in abstract, is to introduce a CC register class and deal with CCs in a fully general way. If so, this is not a small change. Opinions/reactions?