search for: createxxxpass

...cale very well, as I'd have to manually > enumerate all .objs that are transforms and insert this list into > every project that builds an executable that needs them. I only have the problem with the X86TargetMachine because in the case of the optimization passes I explicitly call the createXXXPass functions. 'opt' creates passes by name instead and that's why it gets into trouble. > So there's only two ways of dealing with this. The first is to use > DLLs. To prevent code from being duplicated in multiple DLLs and the > EXE, the bulk of the code in lib/ will ha...

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

Hello, 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 LowerPacked doesn't have this... What should I do? m. PS. Chris, thanks for the feedback on the memory cleanup patch - I'm a bit busy getting LLVM integrated in our app now, but I will incorporate your suggestions and submit a pr...

...ould prevent using overriding methods to disable some functionality. This approach could be useful, but I can't really see how it would work out yet. * Add options to the current passes. I could add an option to the current passes to make them do what I want (either using an option to createXXXPass() and the constructor, or perhaps using a set_XXX_option() methode or something). This might work for SimplifyCFG, since that option could be made a bit more generic, such as "Don't move instructions between blocks" (leaving SimplifyCFG free to merge blocks whenever appropriate)...

...m::WriteBitcodeToFile function is undefined, although I included llvm/Bitcode/ReaderWriter.h: undefined reference to `llvm::WriteBitcodeToFile(llvm::Module const*, std::basic_ostream<char, std::char_traits<char> >&) I also get the same undefined reference error if I call the llvm::createXXXPass and llvm::verifyXXX functions although I included all the files like in the Kaleidoscope tutorial. Everything else works fine though. I'm compiling my project with gcc-4.2 and llvm-config with --libs all and I'm using the RELEASE_22 tag from subversion and Eclipse CDT with managed make (o...

...rten 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 LowerPacked > doesn't have this... What should I do? I just added it. There was no reason to not expose it, we just never got to that point. Note that packed support in LLVM is not complete yet. In particular, here are some of...

..., > I'd much rather you refactor the code to have its constructor take a > configuration struct setting its various settings, than have the various > settings pulled out to llvmcontext. > I believe it would solve the issues I have, yes. That would mean having two versions of every createXXXPass() function, one for default parameters and one taking an options struct. If we ignore the library-loading-library case, I could see this working. > > -Chris > > > -- Thanks, Justin Holewinski -- Thanks, Justin Holewinski -------------- next part -------------- An HTML a...

Is anyone currently working on overhauling the command-line processing code? We're currently having some design issues with this component, and I'd like to start a larger conversation on it. For context, I am talking from an "LLVM as a library" perspective instead of an "LLVM as a set of tools" perspective. In a nut-shell, the problems we are facing are as follows: