search for: x86targetmachine

These two subclasses of X86TargetMachine are basically identical. The *only* thing that's different is the constructor. And that *only* differs in the is64Bit argument that it passes to the X86TargetMachine constructor. Replacing the hard-coded 'true' or 'false' with 'Triple(TT).getArch()==Triple::x86_64' make...

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

...he right direction). >>>> I would have thought that linking with LLVMJIT.lib should suffice... a >>>> VC++ linker issue? >>>> >>>> >>> Try adding this to the link command of your executable: >>> >>> /INCLUDE:_X86TargetMachineModule >>> >>> I should document this somehow. >>> >> Yeah, this is necessary, but not sufficient. I also had to link with >> ExecutionEngineBindings.obj (not JIT.obj as first stated) >> > > So you are using the C bindings. Okay, could...

srs <skaflotten at gmail.com> writes: >>>> Try adding this to the link command of your executable: >>>> >>>> /INCLUDE:_X86TargetMachineModule >>>> >>>> I should document this somehow. >>>> >>> Yeah, this is necessary, but not sufficient. I also had to link with >>> ExecutionEngineBindings.obj (not JIT.obj as first stated) >>> >> >> So you are us...

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...

...JIT.obj (thanks aKor for pointing me in the right direction). >>> I would have thought that linking with LLVMJIT.lib should suffice... a >>> VC++ linker issue? >>> >> >> Try adding this to the link command of your executable: >> >> /INCLUDE:_X86TargetMachineModule >> >> I should document this somehow. > > Yeah, this is necessary, but not sufficient. I also had to link with > ExecutionEngineBindings.obj (not JIT.obj as first stated) So you are using the C bindings. Okay, could someone advise what to do here? Something like the _X8...

...at I was trying to do was to compile a little example with each pass, as the hello world pass in http://llvm.org/docs/WritingAnLLVMPass.html. My intention is to get more acquainted with LLVM, and C++ So, if I want to add machine dependent passes, for example, for the X86, I have to add them in the X86TargetMachine.cpp file, is it right? I am a little confused about where to register passes, though. For instance, the passes "phi-node-elimination", and "TwoAddressInstructionPass" are registered in TwoAddressInstructionPass.cpp and PHIElimination.cpp, but what does determine that the PHI eli...

...to also >> link with JIT.obj (thanks aKor for pointing me in the right direction). >> I would have thought that linking with LLVMJIT.lib should suffice... a >> VC++ linker issue? >> > > Try adding this to the link command of your executable: > > /INCLUDE:_X86TargetMachineModule > > I should document this somehow. > Yeah, this is necessary, but not sufficient. I also had to link with ExecutionEngineBindings.obj (not JIT.obj as first stated) /Stein Roger

Hola Aaron, Just having that code didn't work since the linker still stripped it out, so I have that function called from the code in the system that actually is being used by our app. Kinda grubby, but I include: #include "llvm/lib/Target/X86/X86TargetMachine.h" Which is in the LLVM lib, not the LLVM inc directory. This little maneuver made our Mac builds really unhappy, so we conditionally compile all this goo. I don't remember needing to do anything other than include the lib, the header above, and the bit of code I sent around. I'm s...

I'm trying to add static code generation capabilities to my MCJIT compiler on LLVM 3.4. To that extent I have: targetMachine = engineBuilder.selectTarget(); // ... targetMachine->addPassesToEmitFile(<...>); At first glance this appears to work, but when linking the object file I get the warning: ld: warning: PIE disabled. Absolute addressing (perhaps

...rgetMachine(const Target &T, Stri > > const TargetOptions &Options, > > Reloc::Model RM, CodeModel::Model CM, > > CodeGenOpt::Level OL) > > - : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, false), > > + : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, Triple(TT).getArch()) > > Think this is missing a "==Triple::x86_64” at the end, yes? Nah, I turned that parameter into a Triple::ArchType so that I can pass x86_16 as an o...

Thanks for your response Chuck. >From this and the other responses to my question, it looks like I'm including all the right object files, so it must be something with Visual Studio stripping "dead" code. So, given your response Chuck, I have a few questions. First, what exactly is the code that VStudio seems to be stripping? I might be able to figure out how to prevent it

...cked pass would make sense. Is it easy to add intrinsics to do things like dot product of packed types using SSE instructions? That's probably all I need... > Let me know what you think. In the very short term, the hook exposed to > create the lower packed pass can be plunked into the X86TargetMachine and > get intra function packed types working for you. The patch you did was missing the actual implementation of createLowerPackedPass, so I'm including my own differences -- I guess you don't want to apply the changes to X86TargetMachine as I'm the only one actually generating...

The X86 backend has this code: X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) : .... FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), That is, it uses "4" as local area offset. Based on prior discussion this should mean that the local area starts and address ESP+4. Is this...

Hi all, After creating a new LLVM-based project, I faced an odd problem. ExecutionEngine::create always retuned null. After some investigation I found out that it was due to the target architecture not getting registered. I'm using Visual C++ 2005 and in the X86TargetMachine.cpp file an extern variable X86TargetMachineModule is created to 'ensure' that the module is linked in. It works for the example projects, but not for the one I created. When I write a value to X86TargetMachineModule in another module, all is fine and dandy. Although it's a viable w...

On Mon, 18 Oct 2004, Morten Ofstad wrote: > 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... I'm not sure how your patch fixes it though. The only references added by your change would be within the X86 library. How does this change the sit...

...n* force > an arbitrary .obj file to become part of the executable, one that is > not part of the executable's project. This is sufficient to eliminate > the global variable hack Morten introduced for the X86 target. However I can no longer link it with our main project since the X86TargetMachine symbol is gone, and the intermediate object files are not available to the other project. I can't easily do the same as the fibonacci example does, so I have to put it back to the way it was. > But this still doesn't scale very well, as I'd have to manually > enumerate all .ob...

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... > > I'm not sure how your patch fixes it though. The only references added by > your change would be within the X86 library. How doe...

...he bug report http://llvm.org/bugs/show_bug.cgi?id=15206 > > > Right now, I'm trying to hard code a particular target, and copy part of > the TargetTransformInfo and X86TargetTransformInfo > > to a simple LLVM 3.0 project to try out. So far I'm stuck in > instantiating X86TargetMachine and wondering whether it can be > > created from instances of TargetMachine or TargetData. > > > > Look at tools/opt/opt.cpp or tools/llc/llc.cpp. They both initialize the > target machine using the target data. > > Thanks a lot for the pointer. I'll take a look! B...

...hat it fails to compile(produce bc files) big project like MySQL, where 3.0 has no problem. Right now, I'm trying to hard code a particular target, and copy part of the TargetTransformInfo and X86TargetTransformInfo to a simple LLVM 3.0 project to try out. So far I'm stuck in instantiating X86TargetMachine and wondering whether it can be created from instances of TargetMachine or TargetData. Thank you! Best Regards, Ryan On Thu, Feb 7, 2013 at 10:45 AM, Nadav Rotem <nrotem at apple.com> wrote: > Hi Ryan, > > I think that it would be difficult to back port the CostModel back to >...