search for: coldcc

Hi all, I'm interested in fixing PR14481 (http://llvm.org/PR14481), regarding teaching LLVM that coldcc functions do not clobber any registers. As a brief motivation why: this can have a significant performance benefits and is very useful for instrumenting code with many calls that are executed only very rarely. Ubsan's runtime calls are a good example of this. Attached is my attempt at fixing...

...rne <peter at pcc.me.uk> wrote: >>>>> http://llvm-reviews.chandlerc.com/D443 >>>> >>>> Are you sure we actually *want* to expose this to users? >>>> >>>> I would like to mark the UBSan runtime handler functions as __attribute__((coldcc)), and I think that would make sense for other sanitizers too. >>> >>> Are we now willing to commit to a fixed ABI for coldcc? I thought we hadn't been. >> >> Implementing __attribute__((coldcc)) does not necessarily imply fixing >> the ABI, provided that...

....me.uk> wrote: >>>>>> http://llvm-reviews.chandlerc.com/D443 >>>>> >>>>> Are you sure we actually *want* to expose this to users? >>>>> >>>>> I would like to mark the UBSan runtime handler functions as __attribute__((coldcc)), and I think that would make sense for other sanitizers too. >>>> >>>> Are we now willing to commit to a fixed ABI for coldcc? I thought we hadn't been. >>> >>> Implementing __attribute__((coldcc)) does not necessarily imply fixing >>> the...

...optimization, so > that the field operation is next to the stub call? You'll probably want to do this late in the code generator. > 3) Make LLVM think the stub call is not a real call, so that > callee-saved registers do not get clobbered. LLVM supports calling convetions like "coldcc". The idea of coldcc is that the function is compiled to not clobber callee-save registers. However, in practice, no current code generators do anything special with it, it's compiled like fastcc or ccc. -Chris -- http://nondot.org/sabre/ http://llvm.org/

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

https://is.gd/PrmYlA clang-4.0: error: unable to execute command: Segmentation fault (core dumped) clang-4.0: error: clang frontend command failed due to signal (use -v to see invocation) clang version 4.0.0 (trunk 291576) Target: armv7 Thread model: posix InstalledDir: /opt/compiler-explorer/clang-trunk/bin clang-4.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and

...lund 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 doesn't implement it and hence >> this is ignored. > > Yes, unfortunately the list of call-clobbered registers is fixed at > the moment, so coldcc is mostly ignored by the backend. > > Patches welcome. What would be needed there? I actually trie...

...ary to update the cache - this is expensive but happens only in about 1% of all cases and just calls a function to do it. 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. But what is really bad about this, is that the spilling/reloading ALWAYS happens, regardless if the branch containing the call is taken or not. Since the branch is almost never taken, that is obviously quite bad (but eve...

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 fixed at the moment, so coldcc is mostly ignored by the backend. Patches welcome. > So is there any optimization option I'm missing which could im...

...gt; 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 fixed at >> the moment, so coldcc is mostly ignored by the backend. >> >> Patches welcome. > What would be...

...fepoint_normal_dest unwind label %exceptional_return > > invoke_safepoint_normal_dest: > … > > exceptional_return: > %landing_pad = landingpad { i8*, i32 } > cleanup > %relocate_token = extractvalue { i8*, i32 } %landing_pad, 1 > %obj.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(i32 % relocate_token, i32 13, i32 13) > %obj1.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(i32 % relocate_token, i32 14, i32 14) > ret i64 addrspace(1)* %obj1.relocated1 > > > Each gc.relo...

...pace(1)* %obj1) to label %invoke_safepoint_normal_dest unwind label %exceptional_return invoke_safepoint_normal_dest: … exceptional_return: %landing_pad = landingpad { i8*, i32 } cleanup %relocate_token = extractvalue { i8*, i32 } %landing_pad, 1 %obj.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(i32 % relocate_token, i32 13, i32 13) %obj1.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(i32 % relocate_token, i32 14, i32 14) ret i64 addrspace(1)* %obj1.relocated1 Each gc.relocate needs to take its c...

...code generator. > Therefore when instructions are lowered to target-specific instructions? > >> 3) Make LLVM think the stub call is not a real call, so that >> callee-saved registers do not get clobbered. >> > > LLVM supports calling convetions like "coldcc". The idea of coldcc is > that the function is compiled to not clobber callee-save registers. > However, in practice, no current code generators do anything special with > it, it's compiled like fastcc or ccc. > > As long as there is room for it, and obviously coldcc...

...2 0, i32 -1, i32 0, i32 0, i32 0, i64 addrspace(1)* %obj, i64 addrspace(1)* %obj1) to label %invoke_safepoint_normal_dest unwind label %exceptional_return invoke_safepoint_normal_dest: ... exceptional_return: %landing_pad = landingpad token cleanup %obj.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(token %landing_pad, i32 13, i32 13) %obj1.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(token %landing_pad, i32 14, i32 14) ret i64 addrspace(1)* %obj1.relocated1 Now gc.statepoint return a token type ins...

...2 0, i32 -1, i32 0, i32 0, i32 0, i64 addrspace(1)* %obj, i64 addrspace(1)* %obj1) to label %invoke_safepoint_normal_dest unwind label %exceptional_return invoke_safepoint_normal_dest: ... exceptional_return: %landing_pad = landingpad token cleanup %obj.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(token %landing_pad, i32 13, i32 13) %obj1.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(token %landing_pad, i32 14, i32 14) ret i64 addrspace(1)* %obj1.relocated1 Now gc.statepoint return a token type ins...

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

...i64 16, i32 8, i1 false), !dbg !31 call void @llvm.dbg.declare(metadata %"[]u8"* %bytes, metadata !22, metadata !32), !dbg !31 call fastcc void @write(%"[]u8"* byval %bytes), !dbg !33 ret void, !dbg !35 } ; Function Attrs: cold nobuiltin noreturn nounwind define linkonce coldcc void @__zig_panic(i8* nonnull readonly, i64) #1 !dbg !36 { Entry: %2 = alloca %"[]u8", align 8 %message_ptr = alloca i8*, align 8 %message_len = alloca i64, align 8 store i8* %0, i8** %message_ptr, align 8 call void @llvm.dbg.declare(metadata i8** %message_ptr, metadata !41, met...

...are(metadata %"[]u8"* %bytes, metadata !22, >> metadata !32), !dbg !31 >> call fastcc void @write(%"[]u8"* byval %bytes), !dbg !33 >> ret void, !dbg !35 >> } >> >> ; Function Attrs: cold nobuiltin noreturn nounwind >> define linkonce coldcc void @__zig_panic(i8* nonnull readonly, i64) #1 >> !dbg !36 { >> Entry: >> %2 = alloca %"[]u8", align 8 >> %message_ptr = alloca i8*, align 8 >> %message_len = alloca i64, align 8 >> store i8* %0, i8** %message_ptr, align 8 >> call void...

...t;>>> metadata !32), !dbg !31 >>>> call fastcc void @write(%"[]u8"* byval %bytes), !dbg !33 >>>> ret void, !dbg !35 >>>> } >>>> >>>> ; Function Attrs: cold nobuiltin noreturn nounwind >>>> define linkonce coldcc void @__zig_panic(i8* nonnull readonly, i64) #1 >>>> !dbg !36 { >>>> Entry: >>>> %2 = alloca %"[]u8", align 8 >>>> %message_ptr = alloca i8*, align 8 >>>> %message_len = alloca i64, align 8 >>>> store i8* %0,...

...;> there a reason why llvm doesn't keep around the offsets in the right >> order from very beginning, by pushing the CSRs in increasing order of >> FrameIdxs? > > Now, that you mention it, I remember being down to the same rabbit hole. > With certain calling conventions (coldcc, I think it was which can for > sure expose this for x86), it is possible to generate invalid CFI > directives for the registers in a frame. Especially when XMM registers > must be preserved along with general purpose registers. And the reason > for this was the offset fixing logic with...