search for: mcoption

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 unde...

...^ /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 error...

...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...

...ding of gdb-index, and isn't the default) 2) How to implement the flag: * backend option as it is currently (-mllvm -use-dwarf-ranges-base-address-specifier (maybe drop "-specifier" to make it a bit more terse)) * clang option that maps to * backend option (as currently) * MCOption (programmatic/C++ API rather than command line of a backend option) * LLVM IR attribute on the CU (this feature could be supported on a per-CU basis easiyl enough, thus survive LTO, etc, exactly as the user requested (but really if the user requested this on at least one CU, they probably might...

...^ > /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 &am...

...) ). > > 2) How to implement the flag: > * backend option as it is currently (-mllvm > -use-dwarf-ranges-base-address-specifier (maybe drop "-specifier" to make > it a bit more terse)) > * clang option that maps to > * backend option (as currently) > * MCOption (programmatic/C++ API rather than command line of a backend > option) > * LLVM IR attribute on the CU (this feature could be supported on a > per-CU basis easiyl enough, thus survive LTO, etc, exactly as the user > requested (but really if the user requested this on at least one CU,...

.../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.linuxfounda...

...^ >> /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 MCS...

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 t...

...e default) > 2) How to implement the flag: > * backend option as it is currently (-mllvm > -use-dwarf-ranges-base-address-specifier (maybe drop "-specifier" to make > it a bit more terse)) > * clang option that maps to > * backend option (as currently) > * MCOption (programmatic/C++ API rather than command line of a backend > option) > * LLVM IR attribute on the CU (this feature could be supported on a > per-CU basis easiyl enough, thus survive LTO, etc, exactly as the user > requested (but really if the user requested this on at least one CU,...

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>

...e default) > 2) How to implement the flag: > * backend option as it is currently (-mllvm > -use-dwarf-ranges-base-address-specifier (maybe drop "-specifier" to make > it a bit more terse)) > * clang option that maps to > * backend option (as currently) > * MCOption (programmatic/C++ API rather than command line of a backend > option) > * LLVM IR attribute on the CU (this feature could be supported on a > per-CU basis easiyl enough, thus survive LTO, etc, exactly as the user > requested (but really if the user requested this on at least one CU,...

...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:...

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 tr...

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 @@ -10...