search for: irgen

...I would > suggest adding a EBC target to LLVM first. Otherwise you have no way > to test the clang modifications. As was stated in the last post on this subject, EFI C has integer types that have a size determined at run time. I can't see how this would be integrated into the existing IRGen infrastructure in clang without some serious modification, nor how you would represent these in LLVM IR. Mapping from a language that has variable-sized ints, to a target that has variable-sized ints, via an intermediate representation that does not have variable-sized ints would be tricky, I susp...

On Thu, Dec 16, 2010 at 5:42 PM, Lu Mitnick <king19880326 at gmail.com> wrote: > Hello all, > > I want to the do followings: > > (1) Modify the LLVM front-end(clang) to support EFI C > > (2) Add EFI Byte Code target to LLVM > > I am wondering to know which task should I do first, modify front end or > porting LLVM? > > thanks > > yi-hong As long as

...really significant refactoring of every part of the code generator. While I would like to see this happen, is it really a good idea to put this in the critical path of getting MIR serialized and deserialized? > > Also, if we’re getting crazy here, CodeGen in clang should be renamed to > IRGen, AsmPrinter should be renamed to MCGen, and SelectionDAG should be > replaced ;-) > I'm happy to actually do the CodeGen -> IRGen rename. I actually built the change but didn't submit it because of the concerns of some out-of-tree users of Clang. I still have all the perl scripts...

...lex > was able to move the IR stuff he needed into a separately library > pretty trivially (based on the P.O.C. patch he posted), but if it's > not trivial he should just move on. > > >> Also, if we’re getting crazy here, CodeGen in clang should be > >> renamed to IRGen, AsmPrinter should be renamed to MCGen, and > >> SelectionDAG should be replaced ;-) > > > > I'm happy to actually do the CodeGen -> IRGen rename. I actually > > built the change but didn't submit it because of the concerns of > > some out-of-tree users...

...that happens to have a funny name, and can have its address taken. To be clear, I'm only objecting because I don't want to add complexity to the IR for such a weird corner case. Just brainstorming here, and yes, this is somewhat horrible, but would it be possible to handle this by having IRGen introduce a "thunk" function in the case when ::operator new has its address taken? For example, you could have this pseudo code: auto FP = & ::operator new; // I have no idea how to actually spell this in C++ IRGen into the equivalent of: static void *thunk(size_t NumBytes) {...

...based profiling is done in the front end, and the counters are related to parts do the AST. Their isn't enough information for a backend pass to map them to *anything*. We feed block frequency and branch probability through metadata, much like the sampling based approach, but it happens during irgen in the front end, rather than in a backend pass. While it might be possible to translate the instrumentation format to the profile format, it wouldn't be possible to go the other way, and the translation would be imperfect. -------------- next part -------------- An HTML attachment was scrubbe...

...are no other significant transformations that use profiling > information. We are working on that. Notably, we'd like to add > profiling-based decisions to the inliner Just a quick note about the inliner. Although the inliner itself doesn't know how to use the profile, clang's IRGen has been modified to add an 'inlinehint' attribute to hot functions and the 'cold' attribute to cold functions. Indirectly, PGO does affect the inliner. (We'll remove this once the inliner does the right thing on its own.) > , loop optimizers and the > vectorizer. >...

...chine IR files out of CodeGen without them actually including any CodeGen headers. And all the Machine IR passes like MachineFunctionPass, MachineFunctionAnalysis, etc. will remain in CodeGen. Alex. > > >> Also, if we’re getting crazy here, CodeGen in clang should be renamed > to IRGen, AsmPrinter should be renamed to MCGen, and SelectionDAG should be > replaced ;-) > > > > I'm happy to actually do the CodeGen -> IRGen rename. I actually built > the change but didn't submit it because of the concerns of some out-of-tree > users of Clang. I still ha...

+1. Could those two be subdirectories of one “Machine-Related-Stuff” directory? E.g., MachineStuff/IR MachineStuff/CodeGen Where MachineStuff is something meaningful :). That way, they keep a logic bound, more formal than the naming convention. My 2c. Q. > On May 26, 2015, at 9:28 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 26, 2015, at 1:46 PM, Owen Anderson

...lag to remove these phi nodes. > The problems are: > 1) I use visitLoadInst to collect these load operations, and it seems I > cannot reach these loads that are generated by reg2mem? What is the reason? Clang doesn't generate optimized IR - so if your instrumentation is in Clang's IRGen (clang/lib/CodeGen) it won't see these. Clang generates the unoptimized IR (you can see it with -Xclang -disable-llvm-optzns) I do instrumentation in the opt of llvm. Does clang itself do some optimizations that speed up applications with -O3 compared to -O0? > 2) Is there any way to co...

...'re planning to move, but defined in a source file you're *not* planning to move? (Apparently there have been failed attempts in the past to bring sanity here that I wasn't aware of...) > > > >> Also, if we’re getting crazy here, CodeGen in clang should be renamed to IRGen, AsmPrinter should be renamed to MCGen, and SelectionDAG should be replaced ;-) > > > > I'm happy to actually do the CodeGen -> IRGen rename. I actually built the change but didn't submit it because of the concerns of some out-of-tree users of Clang. I still have all the perl...

...nificant transformations that use profiling >> information. We are working on that. Notably, we'd like to add >> profiling-based decisions to the inliner > Just a quick note about the inliner. Although the inliner itself > doesn't know how to use the profile, clang's IRGen has been modified > to add an 'inlinehint' attribute to hot functions and the 'cold' > attribute to cold functions. Indirectly, PGO does affect the > inliner. (We'll remove this once the inliner does the right thing on > its own.) OT: Can you give me a pointer to t...

...the best idea anyone has was Chris's initial suggestion: IR. So I'd like to minimize the bikeshed discussions on this one. ;] There is one interesting question here: should we move include/llvm/*.h to include/llvm/IR/*.h to match other libraries? 2) clang/lib/CodeGen/... -> clang/lib/IRGen/... I think this name is so painfully obvious that everyone will be happy with this change... ... because it's the biggest change. It will involve a great deal of renaming (CodeGenFunction for example) in order to keep things consistent. Are there other names that are poor choices and are l...

...the object using > the type size the bitfield was defined with (i8, i16, i256). It would > help with improving the heuristic. The downside is that it could lead > to un-optimal code, but that's the situation we have now, so... Okay, but what concretely are you suggesting here? Clang IRGen is emitting accesses with consistent sizes, and LLVM is making them inconsistent. Are you just asking Clang to emit smaller accesses in the hope that LLVM won’t mess them up? John.

...nd verify it, and exit. That only needs the MIR and parser and will root out any dependencies on IR/CodeGen. +1 for everything else BTW, not that we needed another +1. Cheers, Pete > >> >> >>>> Also, if we’re getting crazy here, CodeGen in clang should be renamed to IRGen, AsmPrinter should be renamed to MCGen, and SelectionDAG should be replaced ;-) >>> >>> I'm happy to actually do the CodeGen -> IRGen rename. I actually built the change but didn't submit it because of the concerns of some out-of-tree users of Clang. I still have all t...

...ould be compilation wide. fp_contract provides a very similar set of language features, with both a global flag and a #pragma that can be used at either global or local scope to control semantics thenceforth. We handle that in the AST by storing FPOptions on individual arithmetic expressions, and IRGen propagates that to the individual LLVM instructions it creates. I think that's still the right representation for the AST here, and in fact the way fp_contract implemented means that your job at the Sema will be very easy. The only difference is that IRGen can't be quite as literal because...

...in both cases we can safely say it returns undef, because it's a use-after-scope. I think coming up with a new representation with simpler semantics is the way to go. One allocation or lifetime start, and one deallocation and end. Implementing this in Clang will be tricky, though. Clang's IRGen is supposed to be a dumb AST walk, but it has already strayed from that path. Needs more thought... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141105/e7736105/attachment.html>

Hi, all I want to instrument load/store operations in LLVM IR. And I find the LLVM IR generated with flag -o3 is much more efficient than -o0, so I try to instrument on these optimized LLVM IR, but, some load operations are changed to Phi loads. Then, I try the -reg2mem flag to remove these phi nodes. The problems are: 1) I use visitLoadInst to collect these load operations, and it seems I

On Wed, May 15, 2013 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 15, 2013, at 9:10 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: >> >> 1)

...cussed here without further review. I'm going to keep the first version short, and then open it for others to contribute. Philip On 02/24/2015 02:13 PM, Sean Silva wrote: > SGTM. > > I like your idea of starting "perf tips" as sort of isolated > guidelines for better IRGen. Should allow some nice incremental growth > of the documentation. I expect some stuff will need a bit more > discussion, so I would like this document to be in a directory > docs/FrontendInfo/ or something like that (bikeshed) so that we can > easily split out into new docs as need...