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

Hi all, I have summarized the top 10 compiler passes for Polly when compiling LLVM test-ssuite. Results can be viewed on: https://gist.github.com/tanstar/581bcea1e4e03498f935/raw/f6a4ec4e8565f7a7bbdb924cd59fcf145caac039/Polly-top10 Based on the comparison between "clang -O3" and "polly -O3" listed on:

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

On 08/08/2013 01:29 AM, Star Tan wrote: > Hi all, > > > I have summarized the top 10 compiler passes for Polly when compiling LLVM test-ssuite. Results can be viewed on: > https://gist.github.com/tanstar/581bcea1e4e03498f935/raw/f6a4ec4e8565f7a7bbdb924cd59fcf145caac039/Polly-top10 > > > Based on the comparison between "clang -O3" and "polly -O3"

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 Sat, May 6, 2017, at 04:28 PM, llvm.buildmaster at lab.llvm.org wrote: > The Buildbot has detected a failed build on builder polly-amd64-linux > while building polly. > Full details are available at: > http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/6539 > > Buildbot URL: http://lab.llvm.org:8011/ > > Buildslave for this Build: grosser1 > > Build

Is this a recommended approach/good style/good idea to use dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other is and cast functions). Eugene On Wed, Jul 21, 2010 at 12:42 PM, Gabor Greif <gabor at mac.com> wrote: > Hi all, > > at the moment I am trying to fix an unnecessary iterator dereferencing > in Casting.h and am uncovering several ugly

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

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 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 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, the problem is that it doesn't fit in a native register... or is there something

Hi all, at the moment I am trying to fix an unnecessary iterator dereferencing in Casting.h and am uncovering several ugly things. For example, look at this code: > // dyn_cast_or_null<X> - Functionally identical to dyn_cast, except that a null > // value is accepted. > // > template <class X, class Y> > inline typename cast_retty<X, Y>::ret_type

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

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

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