search for: mcoptions

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

Thank you all for your suggestions! @David, thanks for the advice, I'll check MCOptions again and look into LLVMContext. @Craig, @Aaron, great suggestion, moving the option away from CommandFlags.inc to a more appropriate file and adding an extern declaration to the corresponding header gives me more flexibility and allows me to invoke the option by using -mllvm. From my current under...

...^ /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:232:55: error: too many arguments to function call, expected 3, have 4 MCOptions); ^~~~~~~~~ /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: note: 'createMCAsmBackend' declared here MCAsmBackend *createMCAsmBackend(const MCSubtargetInfo &STI, ^ 2 errors...

...r each function so different source files can have different settings. ~Craig On Mon, Jan 6, 2020 at 1:12 PM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Mostly I've only worked with debug info - so anything that I need passed > down to the backend goes into MCOptions, MCAsmInfo, and things like that. > > If you want to affect the way LLVM middle end optimization passes behave, > that may require a different channel (might find some options on the > LLVMContext? Maybe, but maybe not - perhaps those sort of parameters get > passed straight to the p...

Context: In r309526 (with a followup fix in r309529) I implemented the use of DWARF's debug_ranges base address specifier entries to reduce the number of object file relocations needed for debug_ranges*. * in a particular binary internally, an optimized build had a 70% reduction in debug_ranges.reloc, a 16% decrease in total object size (with compressed debug info and fission) Nico noted

...^ > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:232:55: > error: too many arguments to function call, expected 3, have 4 > MCOptions); > ^~~~~~~~~ > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: > note: 'createMCAsmBackend' declared here > MCAsmBackend *createMCAsmBackend(const MCSubtargetInfo &amp...

On Tue, Aug 8, 2017 at 6:56 AM Nico Weber <thakis at chromium.org> wrote: > On Aug 7, 2017 6:58 PM, "David Blaikie" <dblaikie at gmail.com> wrote: > > Context: > > In r309526 (with a followup fix in r309529) I implemented the use of > DWARF's debug_ranges base address specifier entries to reduce the number of > object file relocations needed for

.../llvm/trunk at 208833 91177308-0d34-0410-b5e6-96231b3b80d8 8454a4b9373bca5d2a8f596ef1c33826171729bd is the first bad commit commit 8454a4b9373bca5d2a8f596ef1c33826171729bd Author: Eric Christopher <echristo at gmail.com> Date: Thu May 15 01:21:56 2014 +0000 Fill in the options in the MCOptions struct directly like the other options. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk at 208834 91177308-0d34-0410-b5e6-96231b3b80d8 Before: http://buildbot.llvm.linuxfoundation.org/builders/2_llvm/builds/8/steps/shell_3/logs/stdio After: http://buildbot.llvm.linuxfoundat...

...^ >> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:232:55: >> error: too many arguments to function call, expected 3, have 4 >> MCOptions); >> ^~~~~~~~~ >> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: >> note: 'createMCAsmBackend' declared here >> MCAsmBackend *createMCAsmBackend(const MCSu...

Hello everyone, I'm currently working on a project that required me to fundamentally modify certain mechanisms of the x86 backend, as well as certain functions within PrologEpilogInserter (so my changes are not confined to a single pass - e.g. they include changes to the x86RegisterInfo constructor). In my current solution, I have added an option within

...ating a new AsmPrinterHandler called, tentatively, SourceInterlave that would be responsible of printing the lines related to the instructions. SourceInterleave would take care of loading the files and making sure the source code lines are emitted as comments. This handler would be enabled through MCOptions (similar to what happens with AsmVerbose). The current option is tentatively called AsmSource. Currently AsmPrinterHandler mechanism looks slightly geared towards debug information but it also used for EH. So I think using it for printing interleaved source is a good fit. - Discussion In case th...

Adrian: any thoughts? Has LLDB been fixed to support this yet? On Tue, Aug 8, 2017 at 6:33 AM Robinson, Paul <paul.robinson at sony.com> wrote: > My inclination would be to use "disable if 32-bit and –ggnu-pubnames" as > the default, > Unfortunately Nico points out that Chrome doesn't currently use -ggnu-pubnames :/ So to continue to work "out of the box"

When using LLVM as a JIT compiler, you can use module.dump() to show the generated intermediate code, which is good. Is there similarly a programmatic way to show the generated x64 machine code in assembly format? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160406/c7d22dab/attachment.html>

On Tue, Aug 8, 2017 at 10:50 AM Robinson, Paul <paul.robinson at sony.com> wrote: > Can gdb handle these? i.e. is it just gold that has the problem? > Yep, it's just gold when it's building the gdb-index (an accelerator table for GDB) > Conditioning on debugger tuning when it's not the debugger that has the > problem… icky. > It does. Though to a lesser

...and how you'd like to communicate it? I promise I'm not trying to be (on purpose at least) particularly dense here, but I just don't have enough information to work with here. I agree that we probably have an API problem - some of which I solved for the mips backend at one point using MCOptions (which I don't really like as a general solution), but a more general solution that'll work and be cleaner is definitely a direction I'd like us to go. -eric > ________________________________________ > From: Eric Christopher [echristo at gmail.com] > Sent: 29 July 2015 21:4...

Hi Eric, The main thing we need to fix is that the selection between ELF32/ELF64 needs to depend on the ABI being N64 and not on whether we used a mips-linux-gnu triple versus a mips64-linux-gnu triple. So 'clang -target mips-linux-gnu' -mips64r2 -mabi=64' should produce an ELF64 and 'clang -target mips64-linux-gnu -mips32r2 -mabi=32' should produce an ELF32. In terms of code,

...t but this no longer works. > I promise I'm not trying to be (on purpose at least) particularly dense here, but I just don't have enough > information to work with here. I agree that we probably have an API problem - some of which I solved > for the mips backend at one point using MCOptions (which I don't really like as a general solution), but > a more general solution that'll work and be cleaner is definitely a direction I'd like us to go. Don't worry, I'm not taking it that way. I'm aware that a lot of this goes against most peoples opinion of what a tri...

Hi Eric, Thanks for getting back to me on this. > I'm not sure I agree with the basic idea of using the target triple as a way of > encoding all of the pieces of target data as a string. I think in a number of > cases what we need to do is either open up API to the back end to specify things, > or encode the information into the IR when it's different from the generic triple.

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

...s(const MachineFunction *MF) const { RESET_OPTION(NoNaNsFPMath, "no-nans-fp-math"); RESET_OPTION(UseSoftFloat, "use-soft-float"); RESET_OPTION(DisableTailCalls, "disable-tail-calls"); + RESET_OPTION(HonorFPExceptions, "honor-fp-exceptions"); TO.MCOptions.SanitizeAddress = F->hasFnAttribute(Attribute::SanitizeAddress); } diff --git a/lib/Transforms/InstCombine/InstCombine.h b/lib/Transforms/InstCombine/InstCombine.h index 6c0d4e7..d18309d 100644 --- a/lib/Transforms/InstCombine/InstCombine.h +++ b/lib/Transforms/InstCombine/InstCombine.h @@ -102...