llvm dev - Oct 2004 - [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>

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>

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.

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/