similar to: [LLVMdev] Improving support for the "Cold" Calling Convention

On Feb 20, 2013, at 7:52 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote: >>> On Feb 20, 2013, at 6:24 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>>> On Wed, Feb 20, 2013 at 6:18 PM, John McCall

On Wed, 7 Nov 2007, Nicolas Geoffray wrote: > Thanks BGB, but at this point I can handle it ;-). The problem is not > how in theory (patch the caller), but how in the LLVM code generation > process. There are three steps for that: > > 1) How to represent the stub in the IR? An intrinsic? An external field > with a ghost linkage? Probably an intrinsic. The trick is making it

On 23 Feb 2013, at 00:26, John McCall <rjmccall at apple.com> wrote: > On Feb 20, 2013, at 7:52 PM, John McCall <rjmccall at apple.com> wrote: >> On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote: >>>> On Feb 20, 2013, at 6:24 PM, Richard Smith <richard at

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

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 doesn't > implement it and hence this is ignored. Yes, unfortunately the list of call-clobbered registers is

Hi, I was investigating some performance issues with llvm JIT-generated code (x86_64), and looking at the assembly it indeed seemed quite suboptimal. In particular, the code is basically implementing some kind of caching. If there's a cache hit, the code just takes the value from the cache, if not it will do whatever is necessary to update the cache - this is expensive but happens only in

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

Hi, What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. This is also the default behavior of the Intel Compiler. In X86InstrControl.td the YMMs are not in "defs" set of call. - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments

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 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 directly correspond to their actual stack locations. In X86FrameLowering's emitCalleeSavedFrameMoves, when emitting DWARF

Hi, > What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. > This is also the default behavior of the Intel Compiler. x86_64 Non-windows targets use the rules defined in the x86_64 abi! > In X86InstrControl.td the YMMs are not in "defs" set of call. The XMMs are subregisters of YMMs, and they are in the

BGB wrote: > > for x86: > I presume LLVM supports inline assembler, and also uses the traditional > frame pointer-based stack layout, but I don't know the details (people who > know LLVM could probably be more helpful here). > > ok, maybe here is an option: > after getting the value (in the created stub), execute a chunk of inline > assembler to modify the caller

On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > I see that you are objecting explicit inline control. > > The main problem is that inlining is absolutely crucial for some > "modern" programming styles. E.g. we use a huge collection of small C++ > template classes and template metaclasses, most of which have very > trivial and limited functionality (think of it

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

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

There is one case where inlining/not-inlining affects correctness. A function which uses alloca() will behave differently in the two cases. You can argue one shouldn't write code like this, but it is legal. Chris Lattner wrote: > On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > >> I see that you are objecting explicit inline control. >> >> The main problem is

Hi David, Sorry to bother you, but I would like to get some suggestions on your recent work of token type. I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid

> On Dec 1, 2015, at 11:14 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > While we support 'opaque' types nested within struct types, they are not exactly battle tested: > > $ cat t.ll > %opaque_ty = type opaque > > %struct_ty = type { i32, %opaque_ty } > > define %struct_ty @f(%struct_ty* %p) { > %load = load %struct_ty,

> I dont have a concrete design right now and I am happy to take any other ideas Three ideas come to mind, none of which are perfect: 1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer intrinsic instead of an extractvalue, and the selector should likewise be extracted with