similar to: [LLVMdev] LowerPacked pass

On Wed, 17 Nov 2004, Morten Ofstad wrote: > Our software uses 4 x float vectors a lot, and I pass these to LLVM as > packed types - but when I do the JIT compile it seems that the > LowerPacked pass is never run so the code generation fails. I noticed > that most other passes have a header file with a public createXXXPass() > function so they can be added to the PassManager, but

Chris Lattner wrote: > Note that packed support in LLVM is not complete yet. In > particular, here are some of the big missing pieces: > > 1. No code generators can generate vector instructions yet (SSE or > altivec, for example). This should be fairly easy to add though. > 2. The lowerpacked pass, which currently converts packed ops into their > scalar counterparts,

Hello, I've been away working on other things so I have not been able to respond to mails on this mailing list for a while. But today I got back and I got the latest version of LLVM from CVS and built it successfully (after I deleted my old config.h which was included instead of the one in the new location)... Jeff Cohen wrote: > OK, there may be some light at the end of the tunnel.

Jeff Cohen wrote: > OK, there may be some light at the end of the tunnel. I *can* 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. > > But this still doesn't scale very well, as I'd have to manually

Chris Lattner wrote: > None, that documentation is out of date and doesn't make a ton of sense > for your application. I would suggest that you implement it in the > context of the SelectionDAG framework that all of the code generators > either currently use or are moving to. I updated the documentation > here:

On Wed, 11 May 2005, Tzu-Chien Chiu wrote: > On Tue May 10 2005, Chris Lattner wrote: >> On Tue, 10 May 2005, Morten Ofstad wrote: >>> Actually, I think it would be better to define the registers as a machine >>> value type for packed float x4, and providing some 'extract' and 'inject' >>> instructions to access individual components... There

On Tue May 10 2005, Chris Lattner wrote: >On Tue, 10 May 2005, Morten Ofstad wrote: >> Actually, I think it would be better to define the registers as a machine >> value type for packed float x4, and providing some 'extract' and 'inject' >> instructions to access individual components... There should also be a >> 'shuffle' instruction

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

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' makes them *actually* identical. Can we just ditch the

Óscar Fuentes wrote: > srs <skaflotten at gmail.com> writes: > > >>>> While testing my compiler on win32 in JIT mode, I ran into a couple of >>>> issues: >>>> >>>> 1. I linked the compiler with the lib files resulting from the cmake >>>> created VS.NET build. While everything built just fine, the >>>>

Hello, I''m struggling my brain with this ajax issue ... Basically I have a form for creating records, and I want to submit it using Ajax. On previous versions of RoR (2.0.2) it was working, but the same methods doesn''t work on 2.2.2, and I started to make changes and changes and read forums and the api, but no way ... <% form_remote_for (:expedient, :url => {:action

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

Hi All, I have run into an issue when writing some LLVM code to read from a C++ structure. The structure as defined in LLVM is { { <4 x float> }, { <4 x float> }, { <16 x float> }, { <4 x float> }, { <4 x float> } }. On Windows, with Visual Studio 2012, the vector members of the structure are packed tightly together. However, LLVM seems to be leaving 32 bytes

I finally plunked down for the beta RSpec bundle and I''m working through the initial example. Although I''m a fairly experienced RSpec user, I''m stlll learning new tricks. Anyway, I''m going though the mastermind example, and everything is going well, except that I decided to also try out the Textmate bundle for Cucumber. I decided to use Ben Mabey''s

>> While testing my compiler on win32 in JIT mode, I ran into a couple of >> issues: >> >> 1. I linked the compiler with the lib files resulting from the cmake >> created VS.NET build. While everything built just fine, the >> ExecutionEngine::create call always returned NULL. The fix was to also >> link with JIT.obj (thanks aKor for pointing me in the

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

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

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

Using dovecot 2.0.13. I went to implement relay-ctrl per directions on the Wiki, and failed. After running it down, as best as I can determine, the problem is that the $IP variable is not getting set (and thus not re-set in the script wrapper). I plunked a "set >> debug" into the script, and the only env var's that are set are as listed below (slightly sanitized for public

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