Morten Ofstad
2004-Oct-18 13:47 UTC
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
Paolo Invernizzi wrote:> There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap...I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to Chris Lattner to decide if my patch goes in or not... To reduce the number of mails, I also include my next patch -- X86 specific code and inline assembly for Visual C, unfortunately I had to use the nasty IncludeFile trick again to get the linker to work.. m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041018/10234652/attachment.txt>
Reid Spencer
2004-Oct-18 14:46 UTC
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
Morten, I have committed all your patches except this one. Chris will need to adjudicate this as changing the allocation can (potentially) change the behavior and/or performance of the code. Patches are here: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041018/019488.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041018/019489.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041018/019490.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041018/019491.html Reid. On Mon, 2004-10-18 at 06:47, Morten Ofstad wrote:> Paolo Invernizzi wrote: > > > There was a similar problem some time ago, and was resolved with alloca. > > I think it's a better solution to use the stack instead of the heap... > > I tend to agree, but the constructors won't get called if it's an object > array -- anyway, this particular case there was no objects, just > pointers and bools so alloca should be fine. I'll leave it to Chris > Lattner to decide if my patch goes in or not... > > To reduce the number of mails, I also include my next patch -- X86 > specific code and inline assembly for Visual C, unfortunately I had to > use the nasty IncludeFile trick again to get the linker to work.. > > m. > > > > ______________________________________________________________________ > Index: lib/Target/X86/X86TargetMachine.cpp > ==================================================================> RCS file: /var/cvs/llvm/llvm/lib/Target/X86/X86TargetMachine.cpp,v > retrieving revision 1.68 > diff -u -r1.68 X86TargetMachine.cpp > --- lib/Target/X86/X86TargetMachine.cpp 8 Oct 2004 22:41:46 -0000 1.68 > +++ lib/Target/X86/X86TargetMachine.cpp 18 Oct 2004 13:43:52 -0000 > @@ -53,8 +53,10 @@ > RegisterTarget<X86TargetMachine> X("x86", " IA-32 (Pentium and above)"); > } > > +void X86TargetMachine::stub() {} > + > unsigned X86TargetMachine::getJITMatchQuality() { > -#if defined(i386) || defined(__i386__) || defined(__x86__) > +#if defined(i386) || defined(__i386__) || defined(__x86__) || defined(_M_IX86) > return 10; > #else > return 0; > Index: lib/Target/X86/X86TargetMachine.h > ==================================================================> RCS file: /var/cvs/llvm/llvm/lib/Target/X86/X86TargetMachine.h,v > retrieving revision 1.25 > diff -u -r1.25 X86TargetMachine.h > --- lib/Target/X86/X86TargetMachine.h 11 Jul 2004 02:44:51 -0000 1.25 > +++ lib/Target/X86/X86TargetMachine.h 18 Oct 2004 13:43:52 -0000 > @@ -29,7 +29,7 @@ > X86JITInfo JITInfo; > public: > X86TargetMachine(const Module &M, IntrinsicLowering *IL); > - > + static void stub(); > virtual const X86InstrInfo *getInstrInfo() const { return &InstrInfo; } > virtual const TargetFrameInfo *getFrameInfo() const { return &FrameInfo; } > virtual TargetJITInfo *getJITInfo() { return &JITInfo; } > @@ -58,7 +58,8 @@ > const X86InstrInfo& ii, > const MachineInstr& MI); > } > - > +static IncludeFile > +X86TARGETMACHINE_INCLUDE_FILE((void*)&X86TargetMachine::stub); > } // End llvm namespace > > #endif > Index: lib/Target/X86/X86CodeEmitter.cpp > ==================================================================> RCS file: /var/cvs/llvm/llvm/lib/Target/X86/X86CodeEmitter.cpp,v > retrieving revision 1.67 > diff -u -r1.67 X86CodeEmitter.cpp > --- lib/Target/X86/X86CodeEmitter.cpp 17 Oct 2004 07:49:45 -0000 1.67 > +++ lib/Target/X86/X86CodeEmitter.cpp 18 Oct 2004 13:43:53 -0000 > @@ -102,21 +102,34 @@ > return Stub; > } > > +#ifdef _MSC_VER > +#pragma optimize("y", off) > +#endif > + > void JITResolver::CompilationCallback() { > +#ifdef _MSC_VER > + unsigned *StackPtr, RetAddr; > + __asm mov StackPtr, ebp; > + __asm mov eax, DWORD PTR [ebp + 4]; > + __asm mov RetAddr, eax; > +#else > unsigned *StackPtr = (unsigned*)__builtin_frame_address(0); > unsigned RetAddr = (unsigned)(intptr_t)__builtin_return_address(0); > +#endif > assert(StackPtr[1] == RetAddr && > "Could not find return address on the stack!"); > > // It's a stub if there is an interrupt marker after the call... > bool isStub = ((unsigned char*)(intptr_t)RetAddr)[0] == 0xCD; > > +#ifndef _MSC_VER > // FIXME FIXME FIXME FIXME: __builtin_frame_address doesn't work if frame > // pointer elimination has been performed. Having a variable sized alloca > // disables frame pointer elimination currently, even if it's dead. This is a > // gross hack. > alloca(10+isStub); > // FIXME FIXME FIXME FIXME > +#endif > > // The call instruction should have pushed the return value onto the stack... > RetAddr -= 4; // Backtrack to the reference itself... > @@ -150,6 +163,10 @@ > StackPtr[1] -= 5; > } > > +#ifdef _MSC_VER > +#pragma optimize( "", on ) > +#endif > + > /// emitStubForFunction - This method is used by the JIT when it needs to emit > /// the address of a function for a function whose code has not yet been > /// generated. In order to do this, it generates a stub which jumps to the lazy > > ______________________________________________________________________ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041018/bae69825/attachment.sig>
Morten Ofstad
2004-Oct-18 16:03 UTC
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
Chris Lattner wrote:> Can you explain what goes wrong without the stub? It's the only part that > I didn't apply.The X86 backend doesn't get registered since there are no references to symbols in X86TargetMachine the object file is never pulled in from the library I create, and thus the static intializer for the RegisterTarget is never called... RegisterTarget<X86TargetMachine> X("x86", " IA-32 (Pentium and above)"); I've tried some other ways to resolve it, but so far I've had no luck .. any suggestions are appreciated, as this is a problem in other places as well - and I'm not happy with the IncludeFile hack, I can well understand why you didn't want to apply it. m.
Chris Lattner
2004-Oct-18 16:12 UTC
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
On Mon, 18 Oct 2004, Morten Ofstad wrote:> To reduce the number of mails, I also include my next patch -- X86 > specific code and inline assembly for Visual C, unfortunately I had to > use the nasty IncludeFile trick again to get the linker to work..I applied most of this here: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041018/019493.html Can you explain what goes wrong without the stub? It's the only part that I didn't apply. Thanks! -Chris -- http://llvm.org/ http://nondot.org/sabre/
Reasonably Related Threads
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
- [LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code