search for: midend

Hi everybody, I see a missed optimization opportunity in LLVM that GCC catches and I'd love to hear community's input. Here's the original C code: 1 char arr[2]; 2 char *get(unsigned ind) { 3 if (ind >= 1) { 4 return 0; 5 } 6 return &(arr[ind]); 7 } The variable `ind` is unsigned so, based on the comparison, if it is not greater or equals to one, than it is

...code size regressions Hi Steve, That commit gives significant performance improvements, so I'm not happy reverting it because of the code size increase. A lot of the code size increase is backend dependent, and I have a set of patches that improves the codegen drastically on ARM at least. The midend is generating better code, and more optimisable code (and it's about 30% more performance too). James On Sat, 21 Nov 2015 at 00:01, Steve King <steve at metrokings.com<mailto:steve at metrokings.com>> wrote: On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <renato.golin at linaro.o...

On Fri, Nov 20, 2015 at 5:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > > Hi, > > We'd need to look precisely at what's causing the code size bloat. The midend commit pointed out by Steve shouldn't cause bloat in and of itself - it should reduce code size. It removes a load of stores and branches. > > I know a backend change I made to ARM isn't behaving as well as it could, and I have patches to fix that. Speculatively reverting midend patch...

...out the return address of a function in an LLVM pass, i.e., the byte address right after the end of the call instruction (so that I can initialize a global variable with the return address of a function for a sanity check). Due to some other constraints, I have to run this pass in somewhere in the midend. At a high level, I want to find the address after a call instruction (my main target is x86_64 for now) at runtime, see the two examples below: 100: e8 ff ff ff ff callq func 105: .marker 100: ff d0 callq *%rax 102: .marker My approach is to find call addresses through a function pass...

On Fri, Nov 20, 2015 at 5:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > We'd need to look precisely at what's causing the code size bloat. The > midend commit pointed out by Steve shouldn't cause bloat in and of itself - > it should reduce code size. It removes a load of stores and branches. > Hi James, Sounds like your patch should have been the best of both worlds, so can you investigate the -Os code size mystery? Does the problem ev...

...B maximum resident set size after: 1.68GB (+17%) llvm-lto clang: before: 2.48GB maximum resident set size after: 3.42GB (+33%) The increases are very large. This is worst-case (non-LTO builds would see the peak usage of the backend masked by the peak of the midend) but still - pretty big. Thoughts? Is this completely no-go? is this something that we *just need* to do? Is crippling the backend architecture to keep memory down justified? Is this something we could enable under an option? Any input appreciated. I can also provide a proof-of-concept patch for p...

...n Nov 4, 2019, at 4:00 PM, James Molloy via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We'd be keen to help out what the community decides to do here. I personally feel it's reasonable that: > - LangRef/DataLayout is updated with semantically coherent changes. > - The midend optimizer is updated by someone who cares about those changes and tests are added that use the new DataLayout. This makes perfect sense to me - if you want the mid-level optimizer to be aware of this, then it makes sense for it to be part of DataLayout. Question though: given that approach, would...

On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 19 November 2015 at 19:08, Steve King via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Does the community have bots or humans tracking code size for -Os >> builds? > > Hi Steve, > > I still haven't got around doing a CI for EEMBC or SPEC on ARM. I do > track

On Wed, Oct 26, 2016 at 9:48 PM, Chris Lattner <clattner at apple.com> wrote: > On Oct 26, 2016, at 1:34 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Tue, Oct 25, 2016 at 10:48 PM, Chris Lattner <clattner at apple.com> > wrote: > >> Responding to both of your emails in one, sorry for the delay: >> >> On Oct 25, 2016, at 11:20 AM,

On Oct 26, 2016, at 1:34 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Oct 25, 2016 at 10:48 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote: > Responding to both of your emails in one, sorry for the delay: > >> On Oct 25, 2016, at 11:20 AM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at

On Tue, Feb 25, 2014 at 5:41 PM, Eric Christopher <echristo at gmail.com>wrote: > On Mon, Feb 24, 2014 at 4:33 PM, Tom Roeder <tmroeder at google.com> wrote: > > > > I'm definitely interested in removing the inline asm bits. I'm not > > sure what you mean by a pseudo-plt, though; do you mean hooking into > > the code that generates the Procedure

...17%) > > > > llvm-lto clang: before: 2.48GB maximum resident set size > > after: 3.42GB (+33%) > > > > The increases are very large. This is worst-case (non-LTO builds would > see the > > peak usage of the backend masked by the peak of the midend) but still - > pretty > > big. Thoughts? Is this completely no-go? is this something that we *just > need* > > to do? Is crippling the backend architecture to keep memory down > justified? Is > > this something we could enable under an option? > > Personally, I thin...

...sarily be exposed to users - clang must add it in certain circumstances for example. I don't think this is particularly different to many other attributes such as nocapture/nounwind, that are exposed to users and can be set by users in exceptional circumstances but are primarily inferred by the midend. James On Thu, 5 Nov 2015 at 16:03 Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Nov 5, 2015 at 10:44 AM, James Molloy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > [Adding llvm-dev and re-stating the situation for llvm-dev's benefit] > > &...

Hello everyone, as stated in the topic ? I would like to know which of above works better with wine... I will be buying laptop soon, and will probably have to chose one of above. Yes I know both Intel and ATI drivers for Linux sucks ? but I would like to know which of them sucks more ;], Nvidia will probably not be an option because of my current cash limitation (beside, I already got pretty

...add it in > > certain circumstances for example. I don't think this is particularly > > different to many other attributes such as nocapture/nounwind, that are > > exposed to users and can be set by users in exceptional circumstances but > > are primarily inferred by the midend. > > Sorry, I was unclear. I meant to Clang users as a language-level > attribute (e.g., [[clang::norecurse]]), not LLVM users as an IR-level > attribute. > > ~Aaron > > > > > > James > > > > On Thu, 5 Nov 2015 at 16:03 Aaron Ballman <aaron at aaro...

On Sat, Nov 2, 2019 at 12:45 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Nov 1, 2019 at 8:40 AM Adrian Prantl via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > On Nov 1, 2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > It seems that there are two possible

...hing like > > llvm.undefined.instr) that would lower to an undefined instruction (like > > ud2 in x86). > > > > I'd appreciate feedback anyone might have about this proposal. > > Creating these intrinsic calls could potentially introduce pessimizations, > as the midend would consider the functions to be used. Though maybe this > doesn't matter if the CFI pass is run late. > > It also seems sort of distasteful to have a function whose sole purpose is > to hold metadata about other functions. The way I've implemented it (see the patch I sent t...

...that uses them. Lowering to instructions was always the testing > sticking point. > > We'd be keen to help out what the community decides to do here. I > personally feel it's reasonable that: > - LangRef/DataLayout is updated with semantically coherent changes. > - The midend optimizer is updated by someone who cares about those > changes and tests are added that use the new DataLayout. > - Developers that don't care about those changes maintain a best-effort > approach, which is exactly what we do right now; there are features that > are tested but ar...

...; a global when it emits it (AsmPrinter). > > (1) and (3) work with LTO. (2) interacts badly with LTO so is discounted. > > (1) requires Clang to perform the decision into exactly what section a > global will go, which is the wrong place for several previously mentioned > reasons (midend optimizations could promote .data -> .bss, clang currently > doesn't have the mechanics to test if an initializer is zero or not, LLVM > does). > > (2) and (3) have the advantage that the section type does not need to be > inferred by LLVM from its name. This means we don'...

...e LLVM developers), is that calling conventions in the IR are primarily related to code generation. As SPIR isn't going to be used for codegen (pass SPIR to some backend / converter that is responsible for that), why worry about the calling convention? All it is is a wart, it doesn't affect midend phases at all. I should note that passing structs (byval or not) in the first parameter as an sret argument is *independent of the LLVM calling convention*, and is done at the Clang level. This is part of LLVM/Clang where responsibility for adhering to an ABI overlaps between the IR-generator and...