search for: x86framelow

Hi, I'm gettign an assertion fail/crash in X86FrameLowering::GetFrameIndexReference when compiling the following bitcode: https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0480b0 I tried removing the llvm.frameaddres calls but that's not it, where can I start looking for what my mistake here is? Code seems to verify just fine. ; #0 0...

...64bit code. so my questions are: 1. my understanding is if a function returns a struct, the caller is responsible for allocating space for the struct and passes a pointer to the callee via RDI, which takes a register away from arguments. is that true? what's the best way to detect that in X86FrameLowering::emitPrologue()? 2. i copied get64BitArgumentGPRs from X86ISelLowering.cpp. i need this so i know which registers to push onto the stack and in which order. should i move it to X86RegisterInfo.cpp? could someone give me a pointer on following the FIXME, ie, how could i get that stuff from t...

...peDescriptor4* @"\01??_R0PAH at 8", i32 > 0, i32** %3] > > If I change either of them to have the %2 in both, it crashes llvm. > > > On 2016-10-17 18:02, Carlo Kok via llvm-dev wrote: > >> Hi, >> >> I'm gettign an assertion fail/crash in >> X86FrameLowering::GetFrameIndexReference when compiling the following >> bitcode: >> >> https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0480b0 >> >> I tried removing the llvm.frameaddres calls but that's not it, where can >> I start looking for what my mistake...

...; Rafael > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- diff --git a/lib/Target/X86/X86FrameLowering.cpp b/lib/Target/X86/X86FrameLowering.cpp index 142e60b..0c5209c 100644 --- a/lib/Target/X86/X86FrameLowering.cpp +++ b/lib/Target/X86/X86FrameLowering.cpp @@ -608,14 +608,12 @@ void X86FrameLowering::emitPrologue(MachineFunction &MF) const { // virtual memory manager are allocated in c...

...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 information, this discrepancy gets fixed up by subtracting the offset reported by MFI->getObjectOffset from the minimum offset for any CSR (this is done by the "Offset = MaxOffset - Offset + saveAreaOffset;" line). Is there a r...

...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 information, this >> discrepancy gets fixed up by subtracting the offset reported by >> MFI->getObjectOffset from the minimum offset for any CSR (this is done >> by the "Offset = MaxOffset - Offset + saveAr...

It's not a solution to the actual bug (which is, as the thread you linked discusses, a problem with the assumption on LLVM's part that the __chkstk function lies within 2GB of the emitted code's address space) but there is a simple workaround: hoist all allocas to the first basic block of your function. This allows the JIT to perform all stack allocations in a single adjustment of the

..._stack_0", from the HiPE Runtime to increase the available stack of a function frame). Touches/Adds: - include/llvm/Target/TargetOptions.h - tools/llc/llc.cpp && - include/llvm/Erlang.h - include/llvm/Target/TargetFrameLowering.h - lib/CodeGen/PrologEpilogInserter.cpp - lib/Target/X86/X86FrameLowering.cpp - lib/Target/X86/X86FrameLowering.h 3) A GC plugin to support precise Garbage Collection (with the problems explained in a previous mail [5]). Touches/Adds: - include/llvm/ErlangGC/ErlangGCPrinter.h - lib/ErlangGC/ErlangGC.cpp - lib/ErlangGC/ErlangGCPrinter.cpp - lib/ErlangGC/Makefile -...

I’ve been experimenting with SEH handling in LLVM, and it seems like the unwind funclets generated by LLVM are much larger than those generated by Microsoft’s CL compiler. I used the following code as a test: void test() { MyClass x; externalFunction(); } Compiling with CL, the unwind funclet that destroys ‘x’ is just two lines of asm: lea rcx, QWORD PTR x$[rdx] jmp ??1MyClass@@QEAA at XZ

...> the available stack of a function frame). > > Touches/Adds: > - include/llvm/Target/TargetOptions.h > - tools/llc/llc.cpp > && > - include/llvm/Erlang.h > - include/llvm/Target/TargetFrameLowering.h > - lib/CodeGen/PrologEpilogInserter.cpp > - lib/Target/X86/X86FrameLowering.cpp > - lib/Target/X86/X86FrameLowering.h > > 3) A GC plugin to support precise Garbage Collection (with the problems > explained in a previous mail [5]). > > Touches/Adds: > - include/llvm/ErlangGC/ErlangGCPrinter.h > - lib/ErlangGC/ErlangGC.cpp > - lib/ErlangGC/Erl...

...omatically mark each stack frame as "owned" by the current thread. I'm not sure where the best place in the LLVM architecture to do this is. As I currently understand it, the concept of a stack frame appears pretty late in target code generation. I've hacked in a hook for this in X86FrameLowering.cpp in the emitPrologue and emitEpilogue methods. Is there a cleaner way I can do this? Is there a way I can subclass the X86 code generator to "hook" those two methods and insert my instrumentation? Is there something I'm missing with runOnMachineFunction? Thank you, Andrew -...

...ons from the general Win32 > > handling code. > > > > That is, > > b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI > > is used and false for Cygwin+MinGW. > FTR, there's already such a method but it is (mis?)used only in > lib/Target/X86/X86FrameLowering.cpp for segmented stacks. > Are segmented stacks actually used with MSVC or is it just the > conditions there should use isTargetMingw() && !is64Bit() instead? > > cc'ing graydon about segmented stacks because I know rust uses them. -eric -------------- next part -----...

Mingw switched abis with the release of gcc 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now mingw (like msvc) given thiscall calling convention to methods by default. I think the last bug blocking us to support the new abi has just been fixed. The question now is how to switch. The attached patches simply switch llvm and clang to the new ABI. This is similar to what

Hi, I'm using LLVM to convert expressions to native assembly, the problem is when LLVM compiles this code: define void @fn_0000000000000000(i8*, i8*, i8*) { bb: %res = alloca i32 %3 = load i32* %res %4 = bitcast i8* %0 to i32* %5 = load i32* %4 %6 = bitcast i8* %0 to i32* %7 = load i32* %6 %8 = xor i32 %5, %7 store volatile i32 %8, i32* %res %9 = load i32* %res %10 = icmp

...arly indicates what the pass would do. Will do. > A bigger question is why is StackSegmenter.{h|cpp} are for? It's empty as far as I can tell. In the `Prologue code emission for X86.', I modify this pass to emit segmented stacks code before function prologues (by calling a function in X86FrameLowering). I organized the code this way since it seemed more elegant than checking for a flag inside the corresponding emitPrologue. -- Sanjoy Das http://playingwithpointers.com

...B; MachineBasicBlock::iterator MBBI; <-- points to where the epilogue would be inserted if (MBBI != MBB.begin() ? MBBI->getPrevNode()->isCall() : MBB.getPrevNode()->back().isCall()) { // insert NOP } However, this did not work because at the stage where I am trying to do this (in X86FrameLowering::emitEpilogue), the MBBs look like this: BB0: ... CALL ... <-- call I am trying to detect EH_LABEL ... <--| these two get eliminated in the final JMP <BB1> <--| emitted code. BB1: <-- the MBB RET <-- MBBI points here So the business of fin...

...to MSVC ABI) that should be exceptions from the general Win32 > handling code. > > That is, > b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI > is used and false for Cygwin+MinGW. FTR, there's already such a method but it is (mis?)used only in lib/Target/X86/X86FrameLowering.cpp for segmented stacks. Are segmented stacks actually used with MSVC or is it just the conditions there should use isTargetMingw() && !is64Bit() instead? > c) We should add CC_X86_Win32_C and CC_X86_Win32_ThisCall and use them > only for MSVC 32-bit ABI. > d) Cygwin and Min...

...on works well. Clearly the _chkstk calls must be emitted with ELF target on Windows as well - why not? I'd like to make a patch and fix this right. I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem thus it is probably required for other reasons. So, should I patch both tests? Is the correct patch removing the test isTargetCOFF() completely? Or enabling it for both COFF or ELF tarrgets? I mean - is there any X86 target that does NOT require this st...

...gram using llc I get the following stack dump: 0 llc 0x00000000016611de 1 llc 0x00000000016616aa 2 libpthread.so.0 0x00007f90105fa270 3 llc 0x0000000000adb030 llvm::MachineFrameInfo::getObjectOffset(int) const + 32 4 llc 0x0000000000e73f1a llvm::X86FrameLowering::getFrameIndexOffset(llvm::MachineFunction const&, int) const + 74 5 llc 0x000000000119bed1 6 llc 0x000000000119bd1e 7 llc 0x00000000011e0dce llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110 8 llc 0x000000000158e363 llv...

...gt;> > handling code. >> > >> > That is, >> > b) We should add a IsTargetWin32 which is true if the MSVC 32-bit ABI >> > is used and false for Cygwin+MinGW. >> FTR, there's already such a method but it is (mis?)used only in >> lib/Target/X86/X86FrameLowering.cpp for segmented stacks. >> Are segmented stacks actually used with MSVC or is it just the >> conditions there should use isTargetMingw() && !is64Bit() instead? Attached is a patch that makes the proposed change to isTargetWin32 and also fixes all the previous uses of isT...