similar to: rL296252 Made large integer operation codegen significantly worse.

This patch only results in relaxing dependencies. This now *allows* new orderings that were not previously allowed, but, the fact that we then actually get such a suboptimal output likely indicates an issue elsewhere, that this allowance is exacerbating. Some observations: 1. For some reason, memop folding seems to be generating seriously non-optimal instructions. It is somehow causing there to

I see we're missing an isel pattern for add producing carry and doing a memory RMW. I'm going to see if adding that helps anything. ~Craig On Mon, Feb 27, 2017 at 8:47 PM, Nirav Davé via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yes. I'm seeing that as well. Not clear what's going on. > > In any case it looks to be unrelated to the alias analysis so barring

Explicitly re-adding a node to be processed doesn't work, because the processing order is canonical. 2017-05-22 11:39 GMT-07:00 Nirav Davé <niravd at google.com>: > You can always explicitly add D to the worklist when you make the > transformation with AddToWorklist. Presuambly this was the cause for your > infinite loop. > > -Nirav > > > On Mon, May 22, 2017 at

The root problem is that, when A gets modified, D doesn't get added back to the worklist. I could match the pattern on A, but the problem remains: when D gets modified, A do not get added back tot he worklist. I also considered ding several round of DAGCombine, but it is very easy to run into infinite loops, even with a fair amount of sanity checks. 2017-05-22 7:30 GMT-07:00 Nirav Davé

I'm trying to optimize a pattern that goes roughly as: A / \ B C \ / D Problem is, when A gets modified, B and C get added back to the worklist, but D doesn't. Readding D to the worklist just create an infinite loop where one process D again and again. Is there a proper way to make this work ? -------------- next part -------------- An HTML attachment was scrubbed...

I don't think that'd work, because it leaves all other backends broken. AFAICT, your transform is simply not a legal transform, with the way the ADDC/ADDE opcodes are currently defined, and to do it you really need to fix the opcode definitions to not involve glue, first. I also note that your transform doesn't actually trigger at all on this particular test case on x86, because the

I'd think i1 would be the proper and correct choice for a carry flag for the generic instruction. I expect that would also make UADDO/USUBO redundant with ADDC/SUBC (which would seem a good outcome). You'd need to make sure the right thing happened when converting from ADDC's 1-bit carry in/out to X86ISD::AD[DC]'s EFLAGS i/o. Right now the conversion can get away with assuming

Would it not make sense to refactor the code so those don't use glue rather than emitting them with glue and then getting rid of it. There are times when we would like to emit these in separate blocks but can't (presumably because of the glue). On Tue, Feb 7, 2017 at 9:15 PM, James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That's seems really odd that

Long story short: https://llvm.org/bugs/show_bug.cgi?id=31890 The backend fails to schedule a given DAG, the reason being that there is an instruction and it glue that needs to be broken apart as they can't be scheduled consecutively. See attached file for a picture of the DAG. Not sure what's the best course of action is, and not sure why this isn't a problem for the X86 backend

> On Jan 4, 2016, at 9:55 AM, Amaury SECHET via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > 2016-01-04 18:21 GMT+01:00 Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>>: > On 01/04/2016 07:32 AM, Amaury SECHET wrote: >> After a bit more investigation, it turns out that because %0 is stored into %1 (after

On Wed, 13 Apr 2016 at 09:38 Amaury SECHET <deadalnix at gmail.com> wrote: > I'd be happy to do it, but this is a bit much high level for me to be > actionable. Can you explain me what I should do to reintroduce them int he > debian packaging ? > On the CMake side, I'm not sure. I think it's just a matter of using the "install()" functions to install them

2015-12-26 18:32 GMT+01:00 Philip Reames <listmail at philipreames.com>: > On 12/26/2015 02:17 AM, Amaury SECHET via llvm-dev wrote: > > I'm trying to fix that bug: https://llvm.org/bugs/show_bug.cgi?id=20049 > > It turns out this is the kind of optimization that I really need, as when > it isn't done, all kind of other optimizations opportunities down the road

On 01/04/2016 07:32 AM, Amaury SECHET wrote: > After a bit more investigation, it turns out that because %0 is stored > into %1 (after bitcast) and so %3 may have access to it and clobber it. Can you give a bit more context? I'm not sure which of the examples you're talking about. > > After a bit of thought, it is correct in the general case, but > definitively something

On Sun, 1 May 2016 at 16:12 Amaury SECHET <deadalnix at gmail.com> wrote: > Some update on this. > > 2016-04-12 18:48 GMT-07:00 Andrew Wilkins <axwalk at gmail.com>: > >> On Wed, 13 Apr 2016 at 09:38 Amaury SECHET <deadalnix at gmail.com> wrote: >> >>> I'd be happy to do it, but this is a bit much high level for me to be >>>

Hi, I'm working on a target which have a variable size for CC (the same size as the arguments). As a result getSetCCResultType, return a variable size. In this commit, at the line DAG.getSExtOrTrunc(SetCC, DL, SelectVT), on my target, you end up generating the Node you are replacing, and so creating a loop in the DAG, which give a whole new meaning to the A in the acronym. Subsequent code

Pretty all is in the title. Is there a reason why this isn't done ? With debian and ubuntu switching to PIE by default, this is become more and more of a hassle to get this working properly, and I'd rather see that fixed in LLVM rather than in each driver that do something with it. Has someone already looked into this ? If so, what are the conclusions ? -------------- next part

I may be wrong here, but legalizing early seems like something that is more likely to prevent optimizations than it is to encourage them. But I guess I don't follow why things like TTI, TII and TLI queries don't suffice for this. CodeGenPrepare will break this sequence up. I would imagine that if the target returns false for isCheapToSpeculateCtlz() and false for canInsertSelect(), the

On Wed, 13 Apr 2016 at 08:10 Amaury SECHET via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I'd like to shime in here. These apt repository used to contain packages > named llvm-3.8-tools containing, amongst other things, the lit python > library used to test llvm. It seems that it went away recently and I have > travis build failing because of this. > > What is

Le 29/03/2016 à 14:17, Yury V. Zaytsev a écrit : > Hi Sylvestre, > ri > On Sat, 12 Mar 2016, Sylvestre Ledru wrote: > >> I am working on it as we speak. Hopefully, most of the 3.8 & 3.9 packages are going to be green by next week. > > Any updates on that? Yes, most of the remaining issues are fixed (the sync to llvm.org/apt was disabled). I will send a summary soon.

I had this on my TODO list for a while, but the recent introduction of inaccessiblememonly makes it suddenly more urgent, as there is a risk to waste effort in duplicated work and/or end up with suboptimal solutions. I collected 2 use cases for inaccessiblememonly : - Allocation like functions. - Runtime functions for managed languages, that touch state that the program itself can never touch