similar to: [LLVMdev] A question about Greedy Register Allocator's reload instruction.

On Wed, Feb 8, 2017 at 6:21 PM, Wei Mi <wmi at google.com> wrote: > I have an issue that I've been wrestling with for quite some time and I'm > hoping that someone with a deeper understanding of the register allocator > can help me with. > > Namely, I am trying to teach RA to split a live range rather than > allocating a CSR. I've attempted a very large number

I have an issue that I've been wrestling with for quite some time and I'm hoping that someone with a deeper understanding of the register allocator can help me with. Namely, I am trying to teach RA to split a live range rather than allocating a CSR. I've attempted a very large number of tweaks to the costs (both existing and experimental ones that I've added). However, despite all

yOn Wed, 23 Mar 2005, Vladimir Prus wrote: >> How is your target different here? Can you give an example of why this >> causes a problem? > > Here's the code which computes the hasCalls flag: > > bool HasCalls = false; > > for (MachineFunction::iterator BB = Fn.begin(), E = Fn.end(); BB != E; ++BB) > for (MachineBasicBlock::iterator I = BB->begin(); I

On Tuesday 22 March 2005 20:34, Chris Lattner wrote: > Can you explain the problem in more detail? Specifically the LLVM code > gneerator assumes that there is some alignment that the stack is required > to have as part of its ABI. For example, in X86 target machine, the stack > is 8-byte aligned on entry to function calls. > > What this means is that the frame info can assume

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed

Hi, Compiling attached test-case, which is reduced version of of uECC_shared_secret from tinycrypt library [1], with --target=arm-linux-gnueabi -march=armv6-m -Oz -S results in reloading of register holding function's address before every call to blx: ldr r3, .LCPI0_0 blx r3 mov r0, r6 mov r1, r5 mov r2, r4 ldr r3,

Hi, I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo. For the following case: void f(int x, int y, int z) { void bar(int, int, int); bar(x, y, z); bar(x, z, y); bar(y, x, z); bar(y, y, x); } it calls foldMemoryOperand twice, and thus converts two calls from blx to bl. callMI->dump() shows the function name "bar" correctly, however in generated

On Jun 4, 2010, at 1:57 AM, <Kalle.Raiskila at nokia.com> <Kalle.Raiskila at nokia.com> wrote: > On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: >> If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. >> > Tried it, and it seems to break quite a big chunk of our tests on SPU :)

Dear guys, I am in need of more of your help. I'm implementing a register allocator, and I am having problems to make it produce correct code. Consider this program here: int main(int argc, char ** argv) { int i, j, sum; i = argv[0][0]; j = argv[0][1]; sum = (i + j) * j; printf("Sum = %d\n", sum); } that maps to this llvm bytecode: entry (0xa785590, LLVM

> > It seems to me that the only instructions > > with dead definitions that I should not remove are the calls. Is it true? > > I would like to know if a code like this below is safe, that is, besides > > call instructions, is there other instructions that must stay in the code > > even if their definitions are dead? > > > > MachineInstr * mi = iter; >

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG',

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

Hi Evan, I incoporated the changes you request but to the following i have got a question: > Also, moving the option > there will allow us to change fastcc ABI (callee popping arguments) > only when this option is on. See Chris' email: I am not to sure on that. because that would make modules compiled with the flag on incompatible with ones compiled without the flag off as

Thanks. This is making a lot more sense now and it's looking like this issue isn't Mips specific. Here's the IR dump before simple register coalescing (note: I've patched the IR printer to print the contents of the regmask): 4480B %vreg260<def> = LDC1 %vreg253, <cp#3>[TF=6]; mem:LD8[ConstantPool] AFGR64:%vreg260 GPR32:%vreg253 4496B %vreg261<def> = FMUL_D32

On Oct 5, 2007, at 10:41 AM, Evan Cheng wrote: > > On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > >> Hi Evan, >> I incoporated the changes you request but to the following i have got >> a question: >> >>> Also, moving the option >>> there will allow us to change fastcc ABI (callee popping arguments) >>> only when this option is

Hi all, When compiling some programs using the Mips backend i'm getting this assert message on lib/CodeGen/LiveInterval.cpp:227: "Range is not entirely in interval!" I don't know yet if it's something that is missing on the backend code or why the range to be removed it outside the interval, does anyone have any clue? A more detailed output is attached. The program i tried

For a long time we have had code for custom lowering of adjustments to the stack pointer. But until recently we did not realise that we were handling only places that provided a fixed-value for such adjustments, and the ISD nodes 'ADJCALLSTACKDOWN' and 'ADJCALLSTACKUP' are only described in our TableGen descriptions for immediates. This hasn't previous mattered as LLVM

> On Jan 30, 2017, at 6:18 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > For a long time we have had code for custom lowering of adjustments to the stack pointer. But until recently we did not realise that we were handling only places that provided a fixed-value for such adjustments, and the ISD nodes ‘ADJCALLSTACKDOWN’ and ‘ADJCALLSTACKUP’ are

Hi, During isel lowering, the backend insertes CALLSEQ_START / CALLSEQ_END target independent nodes to the DAG. These are then selected to X86 specific instructions ADJCALLSTACKDOWN / ADJCALLSTACKUP. At these point, they have a constant arguments which corresponds to the fixed frame size for argument passing. But the size of the stack frame isn't finalized until frame layout has

On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > Hi Evan, > I incoporated the changes you request but to the following i have got > a question: > >> Also, moving the option >> there will allow us to change fastcc ABI (callee popping arguments) >> only when this option is on. See Chris' email: > > I am not to sure on that. because that would make