similar to: [LLVMdev] New Problem: llc -O0: Broken module found, compilation aborted!

Does it make a difference if you give the "-target" option to clang? $ clang -target mips-linux-gnu ch8_3.cpp -o ch8_3.bc -emit-llvm -c The .s file generated this way looks quite different from the one in your email. On Tue, Feb 19, 2013 at 5:06 PM, Jonathan <gamma_chen at yahoo.com.tw> wrote: > I didn't have Mips board. I compile as the commands and check the asm >

I didn't have Mips board. I compile as the commands and check the asm output as below. 1. Question: The distance of caller arg[4] and arg[5] is 4 bytes. But the the callee get every arg[] by 8 bytes offset (arg_ptr1+8 or arg_ptr2+8). I assume the #BB#4 and #BB#5 are the arg_ptr which is the pointer to access the stack arguments. 2. Question: Stack memory 28($sp) has no initial value. If

Which part of the generated code do you think is not correct? Could you be more specific? I compiled this program with clang and ran it on a mips board. It returns the expected result (21). On Tue, Feb 19, 2013 at 4:15 AM, Jonathan <gamma_chen at yahoo.com.tw> wrote: > I check the Mips backend for the following C code fragment compile result. > It seems not correct. Is it my

I check the Mips backend for the following C code fragment compile result. It seems not correct. Is it my misunderstand or it's a bug. //ch8_3.cpp #include <stdarg.h> int sum_i(int amount, ...) { int i = 0; int val = 0; int sum = 0; va_list vl; va_start(vl, amount); for (i = 0; i < amount; i++) { val = va_arg(vl, int); sum += val; } va_end(vl);

Hello, I m trying to test individual O3 optimizations/ replicating O3 behavior on IR. I took unoptimized IR (O0), used disable-o0-optnone via (*clang -O0 -Xclang -disable-O0-optnone*). I read somewhere about *clang -O1 -Xclang -disable-O0-optnone,* so I also tested on this initial IR. I have observed by using individual optimizations, the performance (i.e time) is better when the base/initial

You can also add the -Xclang -disable-O0-optnone flag to your command line. This will disable the implicit optnone when compiling with O0. Cheers, Michael On Mon, Sep 18, 2017 at 7:27 AM +0200, "Craig Topper via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: To prevent optnone from being added you can replace -O0 with "-O1 -Xclang

On Jun 21, 2008, at 2:33 PM, Chris Lattner wrote: > > > $ sdiff -w 120 gcc.size llvm.size > Segment : 1495968 | Segment : 2211617 > Section (__TEXT, __text): 251661 | Section (__TEXT, __text): > 290873 > Section (__DWARF, __debug_frame): 82752 | Section (__DWARF, > __debug_frame): 80240 > Section (__DWARF, __debug_info): 671478 | Section

On Thu, 26 Jun 2008, Evan Cheng wrote: > Are you sure the gcc numbers are right? I think these are gcc 4.0 numbers. I > got: > > Section (__TEXT, __text): 254569 > Section (__DWARF, __debug_frame): 82612 > Section (__DWARF, __debug_info): 841164 It is entirely possible they are 4.0 numbers, sorry I don't recall... -Chris -- http://nondot.org/sabre/

On Feb 11, 2009, at 1:13 PM, Marc de Kruijf wrote: > I am reviving this thread because I am seeing the same thing > (unnatural loops produced by llvm-gcc), but it is not limited to -O0 > -- I am seeing it for -O2 and -O3 as well. > Some of my research work is relying on LoopInfo to provide loop > information for all loops, but it is missing these loops. Is there > any

Hi Marc, > Is there a compelling reason why llvm-gcc does not always produce natural > loops. Is it a code size issue, or are there performance implications as > well? I am seeing a simple 'while' loop compiled to an unnatural loop, > without any gotos, breaks, or continues. What is the reason for this? is it already an unnatural loop when it comes out of the gcc parts of

Chris Lattner writes: > I'm still really interested in making Clang (and thus LLVM) faster at > -O0 (while still preserving debuggability of course). Why? Arnt

Hi all I would like to have access to def-use relationships at O0 , for now after register allocation. So my question is 1. is there any such existing information ? If not, do i need to build it from scratch by traversing all the instructions and operands ? 2. While for now I only need it Post RA but eventually I want to use it before RA as well. Suggestions on how i can go abt that would

On Tue, Nov 22, 2011 at 3:18 AM, Alexander Potapenko <glider at google.com>wrote: > What do you think of the following patch? > Unfortunately, it looks like your email got garbled... Please attach patches as actual files rather than as text at the end of the message, otherwise lots of email software does the wrong thing with them... -------------- next part -------------- An HTML

> Unfortunately, it looks like your email got garbled... Please attach patches > as actual files rather than as text at the end of the message, otherwise > lots of email software does the wrong thing with them... See attached. Sorry for that. -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.patch Type: text/x-patch Size: 1819 bytes Desc: not

On Nov 22, 2011, at 3:25 AM, Alexander Potapenko wrote: >> Unfortunately, it looks like your email got garbled... Please attach patches >> as actual files rather than as text at the end of the message, otherwise >> lots of email software does the wrong thing with them... > See attached. Sorry for that. > <clang.patch> > + EP_EnabledOnOptLevel0 I'd rename

> >> + EP_EnabledOnOptLevel0 > > I'd rename this as EP_AlwaysEnabled > Renamed, see the attachment. But note that one needs to add his pass at two extension points: at O0 and wherever else he wanted to add it. Won't such a name confuse the user? E.g. he may think that just adding a pass as "EP_AlwaysEnabled" should be enough to have it at any optimization

On Tue, Nov 29, 2011 at 8:56 AM, Alexander Potapenko <glider at google.com>wrote: > PS. Should we move the discussion to cfe-commits or it's ok to > continue the review process here? > For future reference, please send patches which touch both LLVM and Clang to llvm-commits and cfe-commits. However, looking at the Clang side of the patch, it is totally fine. =D --------------

On Tue, Nov 29, 2011 at 4:31 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Nov 29, 2011 at 8:56 AM, Alexander Potapenko <glider at google.com>wrote: > >> PS. Should we move the discussion to cfe-commits or it's ok to >> continue the review process here? >> > > For future reference, please send patches which touch both LLVM and Clang

> > Alex, > Now, the patch is actually a bit confusing to me. > EP_AlwaysEnabled should mean "works with O0 after inliner and with >= O1 > somewhere late", but it doesn't look like it works this way (otherwise, you > wouldn't need to call PMBuilder.addExtension twice). > ? This was actually my question to Devang. Any other suggestions for the EP name?

+cfe-commits (as the patch touches both llvm and clang) On Wed, Nov 30, 2011 at 9:33 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: > > >> > >> Alex, > >> Now, the patch is actually a bit confusing to me. > >> EP_AlwaysEnabled should mean "works with O0 after inliner and with >=