[LLVMdev] i1 Values

[Jonathan Roelofs]

On 2/5/15 2:28 PM, dag at cray.com wrote:
> Micah Villmow <micah.villmow at softmachines.com> writes:
>
>> I can see two reasons for it:
>>
>> 1) An integer way to represent -0 and +0 from the floating point domain.
>> 2) unsigned i1 represents 0 and 1(via unsigned values being in the
>> range 0 -> (2^N) - 1, but a signed i1 represents [-]0 and -1(via
>> signed values being in the range -2^(N-1) -> 2^(N-1) - 1.  This could
>> be important when promoting to large integers and determining if sign
>> or zero extension is needed.
>
> Right.  As Nick noted, APInt doesn't provide any information to a user
> to know whether sign- or zero-extension is appropriate.  This makes
> debugging hard as callers can't simply assert that the value is signed
> or unsigned.
>
> Not that I want to add state to APInt but it could be helpful in some
> cases to carry information about an APInt's intended signedness for
> debugging purposes.  As it is now I have to check every user of APInt to
> make sure it's doing the right thing.
>
> Probably there's no good solution for this but it's something to ponder.
This reminds me of something I always wanted when doing language 
frontend work: Statically typed Value*'s. The idea being that in lots of 
places where Value*'s are used, you know the type of the instruction 
you're pointing at, and you want to tell the C++ compiler about that so 
it can help you keep the types straight at compiler-run-time. I imagine 
such a thing could be implemented the same way strong typedefs work. The 
same strategy could probably be used to help with keeping track of 
signedness of APInts, and probably lots of other things.

Unfortunately I never got around to implementing that, so I don't know 
exactly what the pros and cons of it are.


Jon
>
>                              -David
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded