similar to: [LLVMdev] How to handle size_t in front ends?

On May 6, 2008, at 11:12 PM, Talin wrote: > For the most part, it appears that writing a front end can be almost > entirely platform-independent. For example, my front end doesn't know > how big a pointer is, and for the most part doesn't care. All of the > platform-specific aspects of compilation have, up to this point, been > hidden behind the IR. Nice. > However,

On a related topic: The source-level debugging descriptors require you to know up front what the sizeof pointer types are. Is there any hope of the frontend remaining blissfully unaware of platform details? Chris Lattner wrote: > On May 6, 2008, at 11:12 PM, Talin wrote: > > >> For the most part, it appears that writing a front end can be almost >> entirely

On Wed, 21 May 2008, Talin wrote: > On a related topic: The source-level debugging descriptors require you > to know up front what the sizeof pointer types are. Is there any hope of > the frontend remaining blissfully unaware of platform details? I really don't know how to do this. The current debug info stuff depends on emitting size info into the IR. At this point, I don't

On Wed, 7 May 2008, Gordon Henriksen wrote: >> What would this be used for? How is it defined? How does >> arithmetic work on it? > > Looking up the intptr type via TargetData is not a significant issue > for me, but I can see the appeal, and how its absence could constitute > a significant barrier to generating portable IR (provided, of course, > a portable language).

On 2008-05-07, at 03:05, Chris Lattner wrote: > On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > >> There are other languages that specify a "word" type along these >> lines. Would it be worth considering adding such a type to the IR, >> or is there a reason not to do so that I am failing to see? > > What would this be used for? How is it

On Wed, 2008-05-07 at 13:24 -0700, Chris Lattner wrote: > Querying TargetData only works if you know the size of the pointer. :) Yes. For BitC purposes, querying TargetData would be sufficient as long as we don't care whether the emitted IR is neutral w.r.t. pointer size. Given this, I think that introducing an iWord type is not yet sufficiently well motivated from the BitC perspective.

Gordon Henriksen wrote: > On 2008-05-21, at 22:17, Talin wrote: > >> As I understand this, this issue and others like it all require a >> difficult step to be taken, which is to introduce the concept of a >> constant whose value is not known until code generation time or at >> least >> until the compilation target is fully known. These "late bound

Chris Lattner wrote: > On Wed, 21 May 2008, Talin wrote: > >> On a related topic: The source-level debugging descriptors require you >> to know up front what the sizeof pointer types are. Is there any hope of >> the frontend remaining blissfully unaware of platform details? >> > > I really don't know how to do this. The current debug info stuff

On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: >>> 1) Is there a way to declare an integer type in the IR that >>> represents >>> "an int the same size as a pointer" without specifying exactly the >>> size >>> of a pointer? >> >> No. > > Chris: > >

On May 22, 2008, at 6:40 PM, Talin wrote: >> LLVM already does this. >> >> http://www.nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt >> >> — Gordon >> > Is there a similar technique that would allow calculation of the > alignment? (which is also required by the DWARF derived-type > descriptor.) There is more than one form of

On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: > > 1) Is there a way to declare an integer type in the IR that represents > > "an int the same size as a pointer" without specifying exactly the > > size > > of a pointer? > > No. Chris: There are other languages that specify a "word" type along these lines. Would it be worth considering

Chris Lattner wrote: > On May 22, 2008, at 6:40 PM, Talin wrote: > >>> LLVM already does this. >>> >>> http://www.nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt >>> >>> — Gordon >>> >>> >> Is there a similar technique that would allow calculation of the >> alignment? (which is also

On Wed, 7 May 2008, Jonathan S. Shapiro wrote: >> On Wed, 2008-05-07 at 13:24 -0700, Chris Lattner wrote: >> Querying TargetData only works if you know the size of the pointer. :) > In the end, the use case that concerns me is things like character > vectors, because of the fact that the index spans depend on the address > space size. I'm not clear whether it is a goal

On 2008-05-21, at 22:17, Talin wrote: > Chris Lattner wrote: >> On Wed, 21 May 2008, Talin wrote: >> >>> On a related topic: The source-level debugging descriptors require >>> you >>> to know up front what the sizeof pointer types are. Is there any >>> hope of >>> the frontend remaining blissfully unaware of platform details?

On Wed, 2008-05-07 at 14:25 -0700, Chris Lattner wrote: > On Wed, 7 May 2008, Jonathan S. Shapiro wrote: > > >> On Wed, 2008-05-07 at 13:24 -0700, Chris Lattner wrote: > >> Querying TargetData only works if you know the size of the pointer. :) > > > In the end, the use case that concerns me is things like character > > vectors, because of the fact that the

On 2008-05-07, at 16:24, Chris Lattner wrote: > On Wed, 7 May 2008, Gordon Henriksen wrote: > >>> What would this be used for? How is it defined? How does >>> arithmetic work on it? >> >> Looking up the intptr type via TargetData is not a significant >> issue for me, but I can see the appeal, and how its absence could >> constitute a

On Nov 10, 2009, at 4:10 PM, Talin wrote: > I realize that most users of LLVM aren't affected by this, because most frontends aren't target-neutral, and thus know in advance how big a pointer is. At least, that's my impression. I believe that. > There's only a tiny handful of fairly esoteric cases which require selecting a target before you generate IR. Unfortunately, the

When reading this thread it occured to me that one could reserve i0 as an integer type that is semantically identical to iN where N is the size of (i8*) in bits. But on the other hand I just woke up, so this might be a silly idea :-) Cheers, Gabor

On Wed, 7 May 2008, Jonathan S. Shapiro wrote: >> >> i64 should be big enough for this. Just use i64. > > On a 32-bit platform, doesn't one want to use i32? Why? What is wrong with i64? -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Wed, 7 May 2008, Jonathan S. Shapiro wrote: > On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote: >> On Wed, 7 May 2008, Jonathan S. Shapiro wrote: >>>> >>>> i64 should be big enough for this. Just use i64. >>> >>> On a 32-bit platform, doesn't one want to use i32? >> >> Why? What is wrong with i64? > > On its face,