similar to: [LLVMdev] Command Line Flags for LTOModule

Displaying 20 results from an estimated 7000 matches similar to: "[LLVMdev] Command Line Flags for LTOModule"

2013 Jul 16
0
[LLVMdev] Command Line Flags for LTOModule
While looking at adding a new TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? -
2014 Oct 02
2
[LLVMdev] LTOModule::parseSymbols not handling GlobalAlias
Hello everyone, ...I should have used a different subject line in the first place... I've asked Rafael a question about GlobalAlias handling in LTOModule::parseSymbols, but he seems to be on vacation... Does anyone knows the answer? Thanks a lot! Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original
2020 Jan 06
2
Adding a clang commandline option to change backend behaviour
CommandFlags.inc is only included by llc and opt. I think it mostly just sets things on TargetMachine and TargetOptions and connects them to command line options. Clang has its own code for setting up TargetMachine and TargetOptions. I think a lot of configuration things these days tend to be done with function attributes in IR. You can just query the function attribute wherever without any need
2020 Jan 09
2
Adding a clang commandline option to change backend behaviour
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
2015 Jan 12
2
[LLVMdev] Enable changing UnsafeFPMath on a per-function basis
----- Original Message ----- > From: "Reid Kleckner" <rnk at google.com> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, January 12, 2015 2:54:48 PM > Subject: Re: [LLVMdev] Enable changing UnsafeFPMath on a per-function basis > > > > Whatever
2015 Jan 09
5
[LLVMdev] Enable changing UnsafeFPMath on a per-function basis
To continue the discussion I started last year (see the link below) on embedding command-line options in bitcode, I came up with a plan to improve the way the backend changes UnsafeFPMath on a per-function basis. The code in trunk currently resets TargetOptions::UnsafeFPMath at the beginning of SelectionDAGISel::runOnMachineFunction to enable compiling one function with “unsafe-fp-math=true” and
2013 Aug 28
0
[LLVMdev] Adding diversity for security (and testing)
On 08/28/2013 12:01 PM, Stephen Checkoway wrote: > 2. Local attacker who cannot read the contents of the binary. (This is a pretty strange one, but it's possible.) The attacker is forced to rely on side channel information such as timing channels in an attempt to discover the length of the inserted NOP sleds. This sounds like an extraordinarily difficult task, but possibly doable. With a
2013 Aug 26
0
[LLVMdev] Adding diversity for security (and testing)
On Aug 26, 2013, at 11:39 AM, Stephen Crane <sjcrane at uci.edu> wrote: > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by > denying the attacker
2015 Jan 29
0
[LLVMdev] [Mips][TargetOptions] How to properly instantiate TargetOptions in MC layer?
Hi Eric, as I was working on the same issues that are covered in your patch I also made a change in clang driver to pass this option to the assembler. Could you please review it and tell me your opinion? http://reviews.llvm.org/D6091 Thanks Vladimir ________________________________ From: Daniel Sanders Sent: Wednesday, January 28, 2015 8:59 PM To: Eric Christopher; Vladimir Medic; llvmdev at
2015 Jan 27
2
[LLVMdev] [Mips][TargetOptions] How to properly instantiate TargetOptions in MC layer?
Hi all, we have several features in Mips that are dependent on target abi. A recent commit(r224492) introduced a new -target-abi option to TargetOptions struct that provides access to abi string. This info is stored in MCSubtarget class(ARMSubratget in this case) and distributed to other libraries. Unfortunately, for Mips we need this info in other classes that don't have access to MCSubtarget
2013 Aug 27
0
[LLVMdev] Adding diversity for security (and testing)
On Aug 26, 2013, at 2:39 PM, Stephen Crane <sjcrane at uci.edu> wrote: > We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by > denying the attacker information about the exact code layout. Putting on my security hat (as opposed to
2015 Jan 28
3
[LLVMdev] [Mips][TargetOptions] How to properly instantiate TargetOptions in MC layer?
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,
2013 Aug 26
10
[LLVMdev] Adding diversity for security (and testing)
Greetings LLVM Devs! I am a PhD student in the Secure Systems and Software Lab at UC Irvine. We have been working on adding randomness into code generation to create a diverse population of binaries. This diversity prevents code-reuse attacks such as return-oriented-programming (ROP) by denying the attacker information about the exact code layout. ROP has been used is several high-profile recent
2013 Aug 28
0
[LLVMdev] Adding diversity for security (and testing)
On 26 August 2013 11:39, Stephen Crane <sjcrane at uci.edu> wrote: > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by >
2020 Jan 06
2
Adding a clang commandline option to change backend behaviour
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
2013 Aug 29
2
[LLVMdev] Adding diversity for security (and testing)
On 8/28/13 4:37 PM, Nick Lewycky wrote: > On 26 August 2013 11:39, Stephen Crane <sjcrane at uci.edu > <mailto:sjcrane at uci.edu>> wrote: > > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of
2017 Oct 26
2
Autocompletion support for llvm opt flags
Hi all, Thank you for your feedback at the dev meeting. We are planning to add --autocomplete flag to llvm-opt, which enables us to make a new command-line autocompletion for opt when -mllvm is provided to Clang command invocation. There are command-line option's namespace opt::cl in CommandLine.cpp, which provides useful function for parsing options. However we also have OptTable in
2014 Jan 22
2
[LLVMdev] [RFC] LTO: deallocating llvm::Module inside lto_codegen_add_module
LTOCodeGenerator::addModule (which is wrapped by lto_codegen_add_module) takes an LTOModule as an argument and links the latter's llvm::Module into its own. It does not change the latter's llvm::Module. The lto_module_dispose API call destroys an LTOModule. This frees the LTOModule's llvm::Module, but also invalidates strings returned by, e.g., lto_module_get_symbol_name. I propose
2013 Sep 20
2
[LLVMdev] Adding diversity for security (and testing)
Nick, Thanks so much for such a detailed review. I definitely missed a few of the details of the LLVM standards. Sorry. Here's a new patch that should resolve the issues you pointed out. I've also included a few comments below -- anything I haven't replied to has been fixed. In particular, I'd like to discuss RNG seeding with the list. I currently use a static singleton to make
2013 Sep 09
0
[LLVMdev] Adding diversity for security (and testing)
On 29 August 2013 15:29, Stephen Crane <sjcrane at uci.edu> wrote: > On 08/28/2013 02:37 PM, Nick Lewycky wrote: > >> 1. I'm concerned about the deployment problem. I realize that being in >> the compiler means you can transform the program in more exciting ways, but >> it gives you a much worse deployment story than something which modifies >> the program