search for: treessa

Does llvmgcc4 convert the high-level AST to LLVM (like llvmgcc3x) or does it go from GIMPL to LLVM? If the latter, would it be possible to allow some TreeSSA optimizations before emitting LLVM? --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Jul 31, 2006, at 1:10 PM, Devang Patel wrote: > llvmgcc4 emits LLVM byte code before executing GCC optimizations, > so one can say that llvmgcc4 disables all GCC optimizations. > &g...

On Mon, 31 Jul 2006, Devang Patel wrote: > On Jul 31, 2006, at 11:14 AM, Vikram Adve wrote: >> Does llvmgcc4 convert the high-level AST to LLVM (like llvmgcc3x) or does >> it go from GIMPL to LLVM? If the latter, would it be possible to allow >> some TreeSSA optimizations before emitting LLVM? > llvmgcc4 intercepts high-level GCC trees to GIMPLE tree transformation > routines to get trees that are suitable for LLVM byte code. And TreeSSA > optimizer may not be able to handle LLVM suitable GIMPLE trees. One such case > is how Array refere...

On Jul 31, 2006, at 11:14 AM, Vikram Adve wrote: > Does llvmgcc4 convert the high-level AST to LLVM (like llvmgcc3x) > or does it go from GIMPL to LLVM? If the latter, would it be > possible to allow some TreeSSA optimizations before emitting LLVM? llvmgcc4 intercepts high-level GCC trees to GIMPLE tree transformation routines to get trees that are suitable for LLVM byte code. And TreeSSA optimizer may not be able to handle LLVM suitable GIMPLE trees. One such case is how Array references are handled...

...nyway. There definitely are strong advantages to using one datastructure to represent multiple levels of IR: you have less code in the compiler, more shared concepts, etc. I have seen and work with several compilers that tried to do this. Even GCC does this (in the opposite direction) with "treessa" which repurposes some front-end data structures for their mid-level IR. While there are advantages, it also means that you get fewer invariants, and that the data structures are a worse fit for each level. To give you one simple example: LLVM IR is simplified greatly based on the assumption...

llvmgcc4 emits LLVM byte code before executing GCC optimizations, so one can say that llvmgcc4 disables all GCC optimizations. On Jul 31, 2006, at 11:01 AM, Zhiru Zhang wrote: > Hi, > I am trying to turn on the new GCC auto-vectorization feature > within llvmgcc4. Below is the command I used, but nothing was > vectorized. Does it mean that llvmgcc4 has disabled this >

Hi, I am trying to turn on the new GCC auto-vectorization feature within llvmgcc4. Below is the command I used, but nothing was vectorized. Does it mean that llvmgcc4 has disabled this optimization and all I can do is to embed SSE intrinsics in the source code by hand? Thanks! ./llvm-gcc4-x86/bin/llvm-gcc -c -O2 -ftree-vectorize -msse -ftree-vectorizer-verbose=5 -emit-llvm vec.c -o vec.bc

Hi Dan, On 25 Apr 2013, at 01:01, Dan Gohman <dan433584 at gmail.com> wrote: > The main alternative approach that's been discussed is to do FastISel to a target-independent opcode set on MachineInstrs, and then do legalization and ultimately the last phase off instruction selection proper after that. The most obvious advantage of using LLVM IR for legalization is that it's

In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework, it is desirable to implement legalization passes as discrete passes. Attached is a patch which implements the beginning of a new type legalization pass, to help motivate discussion. Is LLVM IR the right level for this? The main alternative approach that's been discussed is to do FastISel to a