search for: add_cc

...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...

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

...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. :-) 4. Do arithmetic in a type with one more bit....

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