On Tue, Oct 1, 2013 at 3:53 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> The option handling in clang in fairly different from opt. The comment > about the mixed name was just a guess as to why you don't see the > driver passing it down to -cc1.Clang::ConstructJob is ~2k lines long. I was putting the handling of this option too far down. I moved it up and it's now being passed. Not sure what order needs to be kept in this function, however.> Once that is working, you will probably need to: > > * Patch ParseCodeGenArgs to record the option > * Patch EmitAssemblyHelper::CreatePasses to set the option to enable > the pass in the pass manager (assuming that is the effect you want).Thanks. That was my disconnect. I was confusing 'opt' with clang's backend. The attached patch does what I want. Does it look like it's in the right direction? Thanks. Diego. -------------- next part -------------- A non-text attachment was scrubbed... Name: 00.diff Type: application/octet-stream Size: 3804 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131001/66c559ac/attachment.obj>
Eric Christopher
2013-Oct-02 00:02 UTC
[LLVMdev] RFH: passing options from clang down to opt
On Tue, Oct 1, 2013 at 4:51 PM, Diego Novillo <dnovillo at google.com> wrote:> On Tue, Oct 1, 2013 at 3:53 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> The option handling in clang in fairly different from opt. The comment >> about the mixed name was just a guess as to why you don't see the >> driver passing it down to -cc1. > > Clang::ConstructJob is ~2k lines long. I was putting the handling of > this option too far down. I moved it up and it's now being passed. > Not sure what order needs to be kept in this function, however. > >> Once that is working, you will probably need to: >> >> * Patch ParseCodeGenArgs to record the option >> * Patch EmitAssemblyHelper::CreatePasses to set the option to enable >> the pass in the pass manager (assuming that is the effect you want). > > Thanks. That was my disconnect. I was confusing 'opt' with clang's backend. > > The attached patch does what I want. Does it look like it's in the > right direction? >Seems pretty reasonable. -eric
Maybe Matching Threads
- [LLVMdev] RFH: passing options from clang down to opt
- [LLVMdev] RFH: passing options from clang down to opt
- [LLVMdev] RFH: passing options from clang down to opt
- [LLVMdev] RFH: passing options from clang down to opt
- [LLVMdev] RFH: passing options from clang down to opt