similar to: [LLVMdev] caller-saved register saving

On Tuesday 08 December 2009 14:43, David Greene wrote: > On Tuesday 08 December 2009 14:00, David Greene wrote: > > I just filed PR 5723. This is a rather serious bug for us, > > causing all sorts of problems in creating dynamically-linked > > C++ programs due to the C++ runtime containing lots of leaf-like > > routines that use thread-local storage. > > > >

I just filed PR 5723. This is a rather serious bug for us, causing all sorts of problems in creating dynamically-linked C++ programs due to the C++ runtime containing lots of leaf-like routines that use thread-local storage. I can imagine a number of hackish workarounds, but I think probably the right way to go is to mark routines with thread-local storage accesses in them as non-leaf. I guess

On Tuesday 08 December 2009 14:00, David Greene wrote: > I just filed PR 5723. This is a rather serious bug for us, > causing all sorts of problems in creating dynamically-linked > C++ programs due to the C++ runtime containing lots of leaf-like > routines that use thread-local storage. > > I can imagine a number of hackish workarounds, but I think probably > the right way to

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

Does not seem that anyone is using the more advanced features of RegScavenger On 02/05/2013 01:09 PM, reed kotler wrote: > I ran into a case in Mips16 where I need two registers. > > The problem arises from the fact that SP is not a mips16 register. > You can implicitly use it in load/store and, move it to/from a mips16 > register and add small immediate values to it but

No. forward() is working correctly. All virtual register references must be resolved before calling it. -Jim On Feb 5, 2013, at 4:05 PM, Reed Kotler <rkotler at mips.com> wrote: > So what I realized is that you can't use the simple scavenger trick where you create the virtual register and use the more advanced features. > > This is because you can't call forward() in any

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

So what I realized is that you can't use the simple scavenger trick where you create the virtual register and use the more advanced features. This is because you can't call forward() in any form if there are virtual registers being used by any of the instructions in the basic block. This will cause forward to fail. Maybe this is a bug in forward() On 02/05/2013 02:51 PM, Reed Kotler

Hi, It has been discovered recently that it is needed for the SystemZ backend to add super-regs to the callee saved regs list like: def CSR_SystemZ : CalleeSavedRegs<(add (sequence "R%dD", 6, 15), - (sequence "F%dD", 8, 15))>; + [R6Q, R8Q, R10Q, R12Q, R14Q], +

I ran into a case in Mips16 where I need two registers. The problem arises from the fact that SP is not a mips16 register. You can implicitly use it in load/store and, move it to/from a mips16 register and add small immediate values to it but that's it. It's not in general a problem for me because there are a bunch of mips32 registers that are hard to use in mips16 so at this time, I

Hi, Two-address instructions are represented as normal three-address instructions with a Desc bit that indicates the first two operands are tied together. The question is, should the second operand have a <kill> flag? a: %R0<def> = MUL %R0, %R1<kill> b: %R0<def> = MUL %R0<kill>, %R1<kill> I think the current policy is a: There should be no kill-flag.

On Jul 14, 2009, at 12:10 PM, Jakob Stoklund Olesen wrote: > Hi, > > Two-address instructions are represented as normal three-address > instructions with a Desc bit that indicates the first two operands are > tied together. The question is, should the second operand have a > <kill> flag? > > a: %R0<def> = MUL %R0, %R1<kill> > b: %R0<def> = MUL

On May 9, 2011, at 9:00 AM, Jonas Paulsson wrote: > Hi, > > I am trying to take 16 bit memory reads and combine them to a single 32 bit read. I am having trouble to make the code simply read 32 bytes and the use the subregisters accordingly, without unnecessary copying. > > I have tried two techniques, in the MachineFunction: > > 1. replace the MachineOperands in the users

Hi Borja, On Jul 10, 2012, at 6:26 PM, Borja Ferrer wrote: > Hello, > > I would like to know if there's a way of setting the callee-saved register list inside getCalleeSavedRegs() to make the PEI pass save/restore only one half of a register pair if the other half is not being used, instead of saving the whole pair. Here is an example of what I try to explain to make things more

Hello, I would like to know if there's a way of setting the callee-saved register list inside getCalleeSavedRegs() to make the PEI pass save/restore only one half of a register pair if the other half is not being used, instead of saving the whole pair. Here is an example of what I try to explain to make things more clear: Suppose this situation where we have a register file of 8bit regs, and

I have a few pass managers, but only one of them has been initialized with addPassesToEmitCode, how do I find how many passes are added to a function pass manager ? Thank you, Xin On Fri, May 20, 2011 at 1:00 PM, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide

> > 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; >

[This feature addresses https://bugs.llvm.org/show_bug.cgi?id=37880 and https://github.com/KSPP/linux/issues/84.] Clang has been ramping up its support of the Linux kernel. We recently added "asm goto with outputs", a long requested feature. We want to continue building our relationship with the Linux community. KSPP is a project to improve security in the Linux kernel, through both

Hi, I just bumped into a bug in this code. The problem was as follows: I have defined a set of registers with rather similar names including digits. The code section at RegisterInfoEmitter::run(){ ... // Process sub-register sets. runs and fills the RegisterAliases map. then, ... for (unsigned i = 0, e = Regs.size(); i != e; ++i) { RegNo[Regs[i].TheDef] = i; NumAliases +=