similar to: [LLVMdev] Bug in x86-64/Win64 Calling Convention

This is the wrong code: declare <16 x float> @foo(<16 x float>) define <16 x float> @test(<16 x float> %x, <16 x float> %y) nounwind { entry: %x1 = fadd <16 x float> %x, %y %call = call <16 x float> @foo(<16 x float> %x1) nounwind %y1 = fsub <16 x float> %call, %y ret <16 x float> %y1 } ./llc -mattr=+avx

On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote: > >> Thanks for giving it a look! >> >> On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: >>> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: >>> >>>> So I saw that the code is doing lots of register >>>>

On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote: > Thanks for giving it a look! > > On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: >> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: >> >>> So I saw that the code is doing lots of register >>> spilling/reloading. Now I understand that due to calling >>> conventions, there's not

On Jan 9, 2012, at 10:00 AM, Jakob Stoklund Olesen wrote: > > On Jan 8, 2012, at 11:18 PM, Demikhovsky, Elena wrote: > >> I'll explain what we see in the code. >> 1. The caller saves XMM registers across the call if needed (according to DEFS definition). >> YMMs are not in the set, so caller does not take care. > > This is not how the register allocator

Hi, I am confused about the call to isPhyRegUsed in calculateCalleeSavedRegisters: if (Fn.getRegInfo().isPhysRegUsed(Reg)) { // If the reg is modified, save it! CSI.push_back(CalleeSavedInfo(Reg)); } It seems that isPhyRegUsed returns true if the register is read or written in the function. If this is right, why do we save a register if it is only read in the function ?? I would have

(repost with right sender address) On 20.10.2010 18:13, Jakob Stoklund Olesen wrote: > On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote: > >> On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: >>> Look in X86InstrControl.td. The call instructions are all prefixed >>> by: >>> >>> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1,

On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote: > On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: >> Look in X86InstrControl.td. The call instructions are all prefixed >> by: >> >> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, >> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, >> XMM0, XMM1, XMM2, XMM3,

Hi (Adding the list back in). On 1 August 2013 08:44, Liu Xin <navy.xliu at gmail.com> wrote: > i know where to calculate CSRs. the additional stack space is calculated in > PEI::calculateCalleeSavedRegisters. the real instructions are inserted in > insertCSRSpillsAndRestores. > my point is why llvm code honor 'naked' but does not 'noreturn' for CSR. And to me

Thanks for reviving this topic! Interestingly we have essentially the same fix you mention below ( https://reviews.llvm.org/D62639) as a local change in our Wind River version of LLVM. The reason we didn't try to push it upstream (and in fact have considered removing it) is due to an unfortunate side-effect which is either "expected" or a "bug" depending on your

For example, I have the following IR code, for.cond.preheader: ; preds = %if.end18 %mul = mul i32 %12, %3 %cmp21128 = icmp sgt i32 %mul, 0 br i1 %cmp21128, label %for.body.preheader, label %return for.body.preheader: ; preds = %for.cond.preheader %19 = mul i32 %12, %3 %20 = add i32 %19, -1 %21 = zext i32 %20 to i64 %22 =

(Changing subject line as diagnosis has changed) I'm attaching the compiled code that I've been getting, both with CodeGenOpt::Default and CodeGenOpt::None . The crash isn't occurring with CodeGenOpt::None, but that seems to be because ECX isn't being used - it still gets set to 0x7fffffff by one of the calls to 76719BA1 I notice that X86::SQRTPD[m|r] appear in

Hi Jakob, I have spent last 4 weeks trying to figure out how to implement Interprocedural Register Allocation. I must admit that I was really overwhelmed with LLVM's codebase while trying to figure this out :) There is so much to know! I think I have reached a point where I have some sort of basic understanding of what needs to be done, but I need some help from here on. So here is the

On Sep 29, 2010, at 8:35 AMPDT, Ralf Karrenberg wrote: > Hello everybody, > > I have stumbled upon a test case (the attached module is a slightly > reduced version) that shows extremely reduced performance on linux > compared to windows when executed using LLVM's JIT. > > We narrowed the problem down to the actual code being generated, the > source IR on both systems

On 31.5.2014 2:04, Pasi Parviainen wrote: > On 28.5.2014 2:57, Sanjoy Das wrote: >> Hi llvmdev, >> >> I'm trying to figure how llvm remembers stack slots allotted to callee >> saved registers on x86. In particular, llvm pushes registers in >> decreasing order of FrameIdxs [1], so the offsets they get (as >> returned by MFI->getObjectOffset) don't

Thanks for giving it a look! On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > >> So I saw that the code is doing lots of register >> spilling/reloading. Now I understand that due to calling >> conventions, there's not really a way to avoid this - I tried using >> coldcc but apparently the backend

On Jan 8, 2012, at 11:18 PM, Demikhovsky, Elena wrote: > I'll explain what we see in the code. > 1. The caller saves XMM registers across the call if needed (according to DEFS definition). > YMMs are not in the set, so caller does not take care. This is not how the register allocator works. It saves the registers holding values, it doesn't care which alias is clobbered. Are you

Hello, Nicolas > The attached patch is a workaround for the XMM misalignment issue. Basically > it uses the fallback method of saving and restoring registers on the stack, > which does work correctly with alignment. If I recall correctly it also > doesn't save any registers unnecessarily, but I could be wrong about that. Please don't use this patch, it's completely wrong.

Hi Peter, The attached patch is a workaround for the XMM misalignment issue. Basically it uses the fallback method of saving and restoring registers on the stack, which does work correctly with alignment. If I recall correctly it also doesn't save any registers unnecessarily, but I could be wrong about that. Anyway, it's hack, but if all you want for now is to be able to work with Win64

I'll explain what we see in the code. 1. The caller saves XMM registers across the call if needed (according to DEFS definition). YMMs are not in the set, so caller does not take care. 2. The callee preserves XMMs but works with YMMs and clobbering them. 3. So after the call, the upper part of YMM is gone. - Elena -----Original Message----- From: Bruno Cardoso Lopes [mailto:bruno.cardoso at

Hi Anton, Thanks a lot for the heads up. I hadn't run into any problems yet with my hack because I haven't used other callee-saved registers so far. Anyway, I'm looking forward to your fix! Kind regards, Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Anton Korobeynikov Sent: zaterdag 1 augustus 2009