search for: gimplifier

Displaying 20 results from an estimated 35 matches for "gimplifier".

Did you mean: simplifier
2007 Nov 07
0
[LLVMdev] RFC: llvm-convert.cpp Patch
On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: > $ more testcase.c.t03.generic > Qux () > { > static char C.0[11] = {0}; > char Bar[11]; > > Bar = C.0; > } > > Anyway, it turns out that the gimplifier was generating the correct > alignment, but it was being overridden in assemble_variable(): > > /* On some machines, it is good to increase alignment sometimes. */ > if (! DECL_USER_ALIGN (decl)) > { > #ifdef DATA_ALIGNMENT > align = DATA_ALIGNMENT (TREE_TYPE (de...
2007 Nov 07
7
[LLVMdev] RFC: llvm-convert.cpp Patch
...an 8-byte alignment. However, the Bar variable has 1-byte alignment, because it's being placed into the "redzone". The generic code for the function is: $ more testcase.c.t03.generic Qux () { static char C.0[11] = {0}; char Bar[11]; Bar = C.0; } Anyway, it turns out that the gimplifier was generating the correct alignment, but it was being overridden in assemble_variable(): /* On some machines, it is good to increase alignment sometimes. */ if (! DECL_USER_ALIGN (decl)) { #ifdef DATA_ALIGNMENT align = DATA_ALIGNMENT (TREE_TYPE (decl), align); #endif #ifdef CONSTAN...
2007 Jul 17
0
[LLVMdev] Review: minor patches to llvm-gcc-4-2
Index: gcc/gimplify.c =================================================================== --- gcc/gimplify.c (revision 39923) +++ gcc/gimplify.c (working copy) @@ -179,8 +179,10 @@ /* LLVM LOCAL begin */ #ifndef ENABLE_LLVM /* LLVM wants to know about gimple formal temps. */ - for (t = gimplify_ctxp->temps; t ; t = TREE_CHAIN (t)) - DECL_GIMPLE_FORMAL_TEMP_P (t) = 0; + if
2007 Jan 11
3
[LLVMdev] Ada support for llvm-gcc4
...ation level is 2, until a better solution is found. 13-optabs.diff Remove all uses of optabs by Ada. These seem to be left-over from older gcc versions: while optabs are initialized, they are not actually used. 14-decl_rtl.diff Use the LLVM version of make_decl_rtl when compiling for LLVM. 15-gimplifier.diff Backport some gimplifier fixes from 4.3. These almost certainly will have no effect on languages other than Ada. With these patches, the Ada build dies at this point: Unhandled expression! <floor_mod_expr 0x40310c08... The Ada bootstrap dies at this point: <view_convert_expr 0x403c...
2007 Jan 11
0
[LLVMdev] Ada support for llvm-gcc4
...t; > 13-optabs.diff > Remove all uses of optabs by Ada. These seem to be left-over from > older gcc versions: while optabs are initialized, they are not > actually > used. > > 14-decl_rtl.diff > Use the LLVM version of make_decl_rtl when compiling for LLVM. > > 15-gimplifier.diff > Backport some gimplifier fixes from 4.3. These almost certainly > will have no effect on languages other than Ada. > > With these patches, the Ada build dies at this point: > Unhandled expression! > <floor_mod_expr 0x40310c08... > > The Ada bootstrap dies at thi...
2005 Aug 15
1
[LLVMdev] cfrontend building
...inline, but it's a nasty job: debugging failures requires pretty > strong understanding of how GCC works. Easier would be to patch the > llvm-gcc X86 configuration stuff to accept and ignore that switch. I looked at those files. Where did you integrate LLVM into GCC? Did you change the gimplifier to produce LLVM code or make LLVM a GCC backend? > > If it's any consolation, it seems fairly likely that there will be a new > llvm-gcc in development in the next couple of months, based on GCC > mainline. > > -Chris Nice to hear that. -------------- next part ------------...
2008 Feb 02
3
[LLVMdev] Problem Compiling llvm-gcc 4.2
>> Dear All, I have been trying for days but still cannot break this barrier. May I get your help? I have compiled llvm-2.1 successfully and make install. When I proceed with llvm-gcc-4.2-2.1, however, I keep getting linking error as attached. Some functions with totally different content conflict with each other in linking process. That is a Linux box (Debian, with 2.6.23-1
2008 Feb 16
0
[LLVMdev] linux/x86-64 codegen support
Andrew Lenharth wrote: > Interestingly, in the .i file there are 2 __builtin_alloca, and > EmitBuiltinAlloca is only being called once. > > Hmm, here EmitBuiltinAlloca gets called twice, but it looks like validate_arglist is rejecting the args both times. I have 2 calls to alloca generated: $ grep alloca x.bc|grep call %tmp21 = call i8* @alloca( i64 %tmp20 ) nounwind
2006 Sep 11
0
[LLVMdev] trying to build llvm-gcc in linux/amd64
On Mon, 11 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am trying to build llvm-gcc4 on a amd64. I had to add the attached > patch to get the build system to select the correct library. Now the Applied. > build fails while compiling a code that has __builtin_va_copy. The > attached test.i fails with: > > cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* >
2008 Feb 16
2
[LLVMdev] linux/x86-64 codegen support
Interestingly, in the .i file there are 2 __builtin_alloca, and EmitBuiltinAlloca is only being called once. Andrew On 2/16/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > libcpp/charset.c:631 turns into: > > %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly > ; <i64> [#uses=1] > %tmp18 = tail call i64 @strlen( i8* %from ) nounwind
2006 Sep 11
5
[LLVMdev] trying to build llvm-gcc in linux/amd64
I am trying to build llvm-gcc4 on a amd64. I had to add the attached patch to get the build system to select the correct library. Now the build fails while compiling a code that has __builtin_va_copy. The attached test.i fails with: cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion `(isAggregateType(((exp)->common.type)) == (DestLoc
2007 Apr 27
2
[LLVMdev] Boostrap Failure -- Expected Differences?
The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the
2009 Jan 09
0
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV().
2007 Nov 07
0
[LLVMdev] RFC: llvm-convert.cpp Patch
...byte alignment, because it's being placed into the "redzone". The > generic code for the function is: > > $ more testcase.c.t03.generic > Qux () > { > static char C.0[11] = {0}; > char Bar[11]; > > Bar = C.0; > } > > Anyway, it turns out that the gimplifier was generating the correct > alignment, but it was being overridden in assemble_variable(): > > /* On some machines, it is good to increase alignment sometimes. */ > if (! DECL_USER_ALIGN (decl)) > { > #ifdef DATA_ALIGNMENT > align = DATA_ALIGNMENT (TREE_TYPE (decl),...
2009 Jun 03
3
[LLVMdev] LLVM-gcc for Ada
Thanks for the suggestion, Andre. I downloaded GNAT GPL 2007, and followed the directions on your web page. Now I get a lot of C++ errors. In fact, the output I captured to a log file is over six megabytes just from the start of the problem command to the termination of the make. I'm obviously not going to include it all here, but the command and the first few errors are copied below.
2010 Mar 09
0
[LLVMdev] Fwd: help with llvm-convert
On alpha, I am seeing a problem with Emiting va_copy.  valists are structs and allocated by alloca, unlike x86.  EmitBuiltinVACopy is therefore using the second branch of the if (~llvm-convert.cpp:6538) to emit the second argument.  The second argument is the result of an alloca.  TreeToLLVM::Emit is hitting the first assertion (~929). The exp being passed is:  <var_decl 0x20000b44240 ap  
2005 Aug 09
0
[LLVMdev] cfrontend building
On Tue, 9 Aug 2005, Stephan Wienczny wrote: > I found the problem. The gcc sources are older than those on my system. I've > got some CFLAGS that the old gcc does not know, eg. -march=pentium-m. Are > these flags filtered out everything works fine ;-) Ok, great! > What are the differences between the cfrontends.tar.gz and the corresponding > gcc release? It's a pretty big
2010 Jan 10
0
[LLVMdev] Cygwin llvm-gcc regression
2010/1/10 Aaron Gray <aaronngray.lists at googlemail.com> > 2010/1/10 Duncan Sands <baldrick at free.fr> > > Hi Aaron, >> >> >> Thanks, okay heres the results :- >>> >>> LLVM type size doesn't match GCC type size! >>> >>> <real_type 0x7ff80b40 long double sizes-gimplified XF size <integer_cst >>>
2007 Nov 07
3
[LLVMdev] RFC: llvm-convert.cpp Patch
...le Johannesen wrote: > > On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: >> $ more testcase.c.t03.generic >> Qux () >> { >> static char C.0[11] = {0}; >> char Bar[11]; >> >> Bar = C.0; >> } >> >> Anyway, it turns out that the gimplifier was generating the correct >> alignment, but it was being overridden in assemble_variable(): >> >> /* On some machines, it is good to increase alignment >> sometimes. */ >> if (! DECL_USER_ALIGN (decl)) >> { >> #ifdef DATA_ALIGNMENT >>...
2008 Mar 27
0
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call