similar to: [LLVMdev] Proper arguments for -march?

Hello, On Fri, Nov 14, 2008 at 6:57 PM, H. Johnson <misc at faradayco.com> wrote: > llc -march=x86 tempfileB.bc yields: > llc: for the -march option: : Cannot find option named 'x86'! Run llc -help and see, if any backends were linked in. It will show you list of all backends, which were 'registered' and thus known to llc. -- With best regards, Anton Korobeynikov

Hi On AArch64 (ARM 64-Bit Platform), I see there is an inconsistency in the values accepted by -march option between clang and llc. --- $ llc -march=aarch64 -mattr=help 2>&1 | grep error $ #No Error $ llc -march=armv8a -mattr=help 2>&1 | grep error llc: error: invalid target 'armv8a'. $ clang -march=armv8a -E - < /dev/null 2>&1 | grep error $ #No Error $

Hi Óscar, On 22/11/12 09:41, Óscar Fuentes wrote: > Luba Tang <lubatang at gmail.com> writes: > >> We found `llvm-config --cxxflags' does not have -fno-exceptions -fno-rtti >> when using cmake to build LLVM. >> Does anyone know how to fix it? > > Using -fno-rtti and -fno-exceptions is an internal LLVM policy. There is > no reason to impose it on client

Hi, Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the spiller's class? Thanks, -- Silvio Ricardo Cordeiro --------------

Hi guys, I have been using a debugger for my register allocator. The debugger happened to be very useful at catching register assignment errors. I've put the debugger on-line, if anyone who is working with register allocation wants to use. The debugger itself has nothing to do with LLVM, but I've coded a spiller that prints the code in a format that the debugger can read. The

Can someone explain the theory behind the spillers in VirtRegMap.cpp? It seems as though the spillers do triple duty: - Insert load/store operations and/or fold instructions as necessary to carry out spills - Rewrite the spilled virtual registers to use machine registers (mapping given by the caller in the VRM). - Rewrite machine code to change virtual registers to physical registers

I'm not sure about one thing: you assign stack slot to each new register you replace the spilled one with. And then you need to allocate physical registers to them. Is it possible to assign physical register to the virtual one which has a stack slot already? On 8/21/06, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > > So what addIntervalsToSpills

Spiller::Spill( LiveInterval *li, SmallVectorImpl<LiveInterval*> &newIntervals, const SmallVectorImpl<LiveInterval*> &spillIs ); has two reference vectors which contain a small list of Live Intervals. What is the register allocator's job to do with these intervals other than analysis. What more needed other than to know

Hi, When setting -mattr option on X86, I would like to treat MMX separately from SSE levels. This would allow a client who sets the attributes directly to set the SSE level independent of MMX, e.g., llc -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If anyone objects to this change, please let me

Hi all, I am working on an out-of-tree target. I am wondering if it is possible to force the register allocator (and/or spiller) to not break certain instruction sequence. For example: phys_reg = MI1 vreg1 vreg 2 = MI2 phys_reg Is there a way to tell RA/spiller not to insert COPY or spill between MI1 and MI2? I am using greedy register allocator and inline spiller. -- Regards, Dongrui

On Monday 06 August 2007 12:15, Anton Vayvod wrote: > Spill intervals must be precolored because they can't be spilled once more. > They are the shortest intervals precisely over each def/use of the original > interval. That is why they also have their weights set to #INF. Yes, that's true. But I wonder if we shouldn't be smarter about which register we pick to color it.

On Aug 17, 2007, at 4:17 PM, Fernando Magno Quintao Pereira wrote: > > Hi guys, > > I have been using a debugger for my register allocator. The > debugger > happened to be very useful at catching register assignment errors. > I've > put the debugger on-line, if anyone who is working with register > allocation wants to use. The debugger itself has nothing to

On Wed, Jul 15, 2015 at 1:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > IMHO, This doesn't make a lot of sense to turn off this part on it's own. > I would just use the enable-pre flag to turn off scalar PRE, as it > will cause the same issue in other cases as well. > Is there some reason you aren't just doing that? > I suspect if this is a performance

Hi Quentin, Let me clarify if I understood this correctly. If the accesses (writes and reads) to sub-registers are expressed always as sub-registers of the super-register register class (e.g., SuperReg.sub1;), then the spilling decision is for the super register. But, if the accesses are in terms of the register class of the sub-registers directly (SubReg;), then the spilling decision will

On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the

I thought about a little bit more, I think adding Register pressure control in your patch or PRE may be the only choice. Because at least for this case I am looking at, what your patch did is created more relatively complex long live range, rematerialization is not smart enough to undo your change or at least without a lot of work, coalescing only create even longer live range not shorter,

On Thu, 20 Apr 2006, Simon Burton wrote: >>> From what I remember, this is a bug in debian libc: >> some floating point flags are set incorrectly causing SIGFPE. >> Can't find the bug report ATM. > > Oh, it just showed up on numpy-discussion: > http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 > > """ > #include <fenv.h> > void

On Mon, 6 Aug 2007, David Greene wrote: >> split into smth like [10, 40) and [40, 50). The former part should not be >> precolored as it has less conflicts (it doesn't intersects with [40, 45) ) >> and can be colored entirely by one register on the next iteration. > > Right. Live range splitting would indeed be nice to have. Bill's > implementation has a

Hi Matthias, No. I want the register allocator to spill the super-register (the large one e.g., 64-bit) and not just the sub-register (e.g., the 32-bit that is a piece of of the 64-bit register) because the stack loads/store width is 64-bit in this example. RegClass1 (sub-registers): sub_registers (32-bit) --> can be natively used in arithmetic operations but no stack

Fernando Magno Quintao Pereira wrote: >> I'm not sure about one thing: you assign stack slot to each new register you >> replace the spilled one with. And then you need to allocate physical >> registers to them. Is it possible to assign physical register to the virtual >> one which has a stack slot already? >> > > Yes. The stack slot is the place where the