similar to: [RFC] Adding function attributes to represent codegen optimization level

Displaying 20 results from an estimated 901 matches similar to: "[RFC] Adding function attributes to represent codegen optimization level"

2018 Apr 04
2
[RFC] Adding function attributes to represent codegen optimization level
On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO
2018 Apr 04
1
[RFC] Adding function attributes to represent codegen optimization level
Sorry, my reply “to all” left out LLVM-Dev From: Martin J. O'Riordan [mailto:MartinO at theheart.ie] Sent: 04 April 2018 16:41 To: 'David Blaikie' <dblaikie at gmail.com>; 'mcrosier at codeaurora.org' <mcrosier at codeaurora.org>; 'Chandler Carruth' <chandlerc at gmail.com>; 'Eric Christopher' <echristo at gmail.com> Subject: RE:
2018 Apr 04
1
[RFC] Adding function attributes to represent codegen optimization level
Hi Martin, I think this is another example of why we might consider having such function level attributes.. yes.  Chad On 4/4/2018 11:42 AM, Martin J. O'Riordan via llvm-dev wrote: > > Sorry, my reply “to all” left out LLVM-Dev > > *From:*Martin J. O'Riordan [mailto:MartinO at theheart.ie] > *Sent:* 04 April 2018 16:41 > *To:* 'David Blaikie'
2018 Apr 05
1
[RFC] Adding function attributes to represent codegen optimization level
Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a écrit : > All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO
2018 Apr 05
1
[RFC] Adding function attributes to represent codegen optimization level
On 2018-04-04 22:00, Mehdi AMINI wrote: > Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a > écrit : > >> All, >> A recent commit, D43040/r324557, changed the behavior of the gold >> plugin >> when compiling with LTO. The change now causes the codegen >> optimization >> level to default to CodeGenOpt::Default (i.e.,
2018 Apr 06
2
[RFC] Adding function attributes to represent codegen optimization level
On Thu, Apr 5, 2018 at 8:44 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 2018-04-04 22:00, Mehdi AMINI wrote: > >> Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a >> écrit : >> >> All, >>> A recent commit, D43040/r324557, changed the behavior of the gold >>> plugin >>> when compiling
2018 Apr 09
1
[RFC] Adding function attributes to represent codegen optimization level
On Fri, Apr 6, 2018, 1:56 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Apr 5, 2018 at 8:44 AM, via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > >> On 2018-04-04 22:00, Mehdi AMINI wrote: >> >>> Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a >>> écrit : >>>
2017 Dec 06
2
[AMDGPU] Strange results with different address spaces
> On Dec 6, 2017, at 02:28, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > > The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1. This sounds possibly problematic to me. The IR should be created with the correct address space to begin with. Changing this in the middle sounds suspect. > After this
2017 Aug 22
2
Subtarget Initialization in <ARCH>TargetMachine constructor
Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,
2018 Jan 11
1
wasm: Bad codegen for i8 comparison
(Currently using a build from november but I didn't see any commit that could fix this for wasm); With the wasm backend, %2 = icmp sgt i8 %0, -1 becomes: i32.const $4=, 255 i32.const $2=, 255 i32.and $3=, $0, $2 i32.const $5=, 255 i32.and $6=, $4, $5 i32.gt_s $7=, $3, $6 Which essentially does
2018 Jan 11
2
wasm: Bad codegen for i8 comparison
Hello, Can you check whether your build includes r317710 <https://llvm.org/svn/llvm-project/llvm/trunk at 317710>? Thanks, Dan On Thu, Jan 11, 2018 at 12:51 AM, Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (Currently using a build from november but I didn't see any commit that > could fix this for wasm); With the wasm backend,
2018 May 29
1
My own codegen is 2.5x slower than llc?
What percentage of performance advantage do you expect to get from having a basic block with 14000 instructions, rather than breaking it up a bit? On Wed, May 30, 2018 at 12:02 AM, David Jones via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My back-end code generator uses LLVM 5.0.1 to optimize and generate code > for x86_64. > > If I run it on a given sample of IR, it
2018 May 29
2
My own codegen is 2.5x slower than llc?
My back-end code generator uses LLVM 5.0.1 to optimize and generate code for x86_64. If I run it on a given sample of IR, it takes almost 5 minutes to generate object code. 95%+ of this time is spent in MergeConsecutiveStores(). (One function has a basic block with 14000 instructions, which is a pathological case for MergeConsecutiveStores.) If, instead, I dump out the LLVM IR, and manually
2018 May 07
1
How to add assembly instructions in CodeGen
One place to look might be in the MachineOutliner target hooks in X86InstrInfo and AArch64InstrInfo. The MachineOutliner runs extremely late in the pass pipeline so it might be a good place to look for some inspiration. Of course, because this is *extremely late* it might not do *exactly* what you need. (e.g, this is post-register allocation, post frame-lowering, etc.) - Jessica > On May 4,
2018 May 29
1
My own codegen is 2.5x slower than llc?
> On 29 May 2018, at 22:02, David Jones via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > My back-end code generator uses LLVM 5.0.1 to optimize and generate code for x86_64. > > If I run it on a given sample of IR, it takes almost 5 minutes to generate object code. 95%+ of this time is spent in MergeConsecutiveStores(). (One function has a basic block with 14000
2018 Mar 19
1
Suggestions for how coroutines and UBSan codegen can play nice with one another?
Hello all! (+cc Vedant Kumar, who I've been told knows a lot about UBSan!) I am trying to fix an assert that occurs when the transforms in llvm/lib/Transforms/Coroutines are applied to LLVM IR that has been generated with UBSan enabled -- specifically, '-fsanitize=null'. You can see an example of the assert in this 26-line C++ file here:
2018 May 05
2
How to add assembly instructions in CodeGen
Hello, I want to add assembly instructions at certain points in a function. This is X86 specific. So I am working in the lib/Target/X86 folder. I create a `MachineFunctionPass` in that folder. I register it in the X86TargetMachine.cpp in addPreEmitPass(). I use BuildMI to insert my own assembly instructions in the MachineFunctionPass. This works and my assembly instructions are inserted
2018 May 08
1
DEBUG INFO: improve handling of DBG_VALUEs and DebugLocs in CodeGen
Hi, (Resent with proper subject line) I recently found myself in trouble because the crash I had disappeared with -g, so I could not debug the program. This happened because the optimizer did not remember to consider DBG_VALUEs instruction so it changed its behavior, and the bug went hiding. I then started discussing this
2018 May 09
1
How to add assembly instructions in CodeGen
Hi Dean, I looked at XRay. I also thought on the similar line to add assembly instructions as auxiliary template code and jump on to there. However, that may still dis-align the stack. I have to think about it. But your XRay code does give me the courage to think about this seriously. Thank you for your help. I also figured out that we can access certain CodeGen's feature right from the IR
2018 Mar 19
1
Suggestions for how coroutines and UBSan codegen can play nice with one another?
> On Mar 19, 2018, at 3:44 PM, Brian Gesiak <modocache at gmail.com> wrote: > > Hello all! > (+cc Vedant Kumar, who I've been told knows a lot about UBSan!) > > I am trying to fix an assert that occurs when the transforms in llvm/lib/Transforms/Coroutines are applied to LLVM IR that has been generated with UBSan enabled -- specifically,