On 07/23/2013 05:19 AM, Konstantin Tokarev wrote:> > 23.07.2013, 16:05, "reed kotler" <rkotler at mips.com>: >> When I use -Os with a clang that implicitly calls llc, I get much >> different code than when call clang first with -Os and then call llc. > clang does NOT call llc internally.I understand. It's invoking that functionality is what I meant to say but not technically running that command.> >> How do I get these two paths to generate the same code? > Call llc with -Os?You can't pass -Os to llc. -Os is a clang only option. It's reflected in the IR used by llc in the function attributes.
On Jul 23, 2013, at 5:22 AM, reed kotler <rkotler at mips.com> wrote:> On 07/23/2013 05:19 AM, Konstantin Tokarev wrote: >> >> 23.07.2013, 16:05, "reed kotler" <rkotler at mips.com>: >>> When I use -Os with a clang that implicitly calls llc, I get much >>> different code than when call clang first with -Os and then call llc. >> clang does NOT call llc internally. > I understand. It's invoking that functionality is what I meant to say but not technically > running that command.This isn’t just a nitpick. This is exactly why you’re seeing differences. The pass managers aren’t always set up the same, for example. FWIW, I feel your pain. This is a long-standing weakness of our infrastructure. -Jim>> >>> How do I get these two paths to generate the same code? >> Call llc with -Os? > You can't pass -Os to llc. > > -Os is a clang only option. It's reflected in the IR used by llc in the function attributes. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130723/3ff107c0/attachment.html>
On 23 July 2013 19:36, Jim Grosbach <grosbach at apple.com> wrote:> This isn’t just a nitpick. This is exactly why you’re seeing differences. > The pass managers aren’t always set up the same, for example. > > FWIW, I feel your pain. This is a long-standing weakness of our > infrastructure. >Jim, A while ago I proposed that we annotated the options the front-end passed to the back-end on the IR with named metadata, but it didn't catch on. Would it make sense to have some call-back mechanism while setting back-end flags to keep a tab on what's called and have a dump as metadata, so that you can just write it to the IR file at the end? More or less what we have for functions, currently. This would hint llc, lli and others to what flags it must set itself (architecture, optimizations, etc) and would minimize the impact of split compilation. Those tools are free to ignore any option it doesn't recognize, of course, as with any metadata. Another way would be to teach llc, lli and others all command line options of all supported front-ends, but that wouldn't be very productive, I think. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130723/afb33332/attachment.html>
On 7/23/2013 1:36 PM, Jim Grosbach wrote:> > This isn’t just a nitpick. This is exactly why you’re seeing > differences. The pass managers aren’t always set up the same, for example. > > FWIW, I feel your pain. This is a long-standing weakness of our > infrastructure.What was the motivation for this design? Was it to save time by not creating another process, or were there other factors? The IBM compiler for example, has all of its components in different executables. It makes debugging a lot more convenient (especially when working with large applications built with IPA). -K -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation