search for: sechet

...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 2:07 PM, Amaury SECHET <deadalnix at gmail.com> > wrote: > >> 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. >> &...

...e they're using a normal value. (Actually, I wonder if it would be possible to represent x86's EFLAGS.CARRY as a 1-bit subreg of EFLAGS, and use that on input to X86ISD::ADC; that may allow cheaper spills/reloads if it only has to save the one bit?). On Wed, Feb 8, 2017 at 7:28 PM, Amaury SECHET <deadalnix at gmail.com> wrote: > Well I don't think this would break most backend. The opcode is generate > only if the backend allows so to boot, so many backend actually do not use > it at all. > > Anyway, changing these opcode is kind of much broader scope than what I...

...which the transform doesn't match. That is not really relevant to the issue here, because the x86 backend does work even if the transform gets triggered (replacing the final store with "store i64 %add37, i64* %r, align 8" will make this happen) On Tue, Feb 7, 2017 at 5:44 PM, Amaury SECHET <deadalnix at gmail.com> wrote: > Making this a value instead of a glue looks like a good longer term > solution, but it doesn't quite cut it as a short term one. It would require > to change a fair amount of code in the DAG stack, plus in each backend. > > @James, > do...

...; wrote: > That's seems really odd that ADDC/ADDE uses glue there, instead of a plain > value. > > The x86 backend has code that converts the glue into a value, which is why > it wasn't affected.... (LowerADDC_ADDE_SUBC_SUBE). > > On Tue, Feb 7, 2017 at 2:48 PM, Amaury SECHET via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 t...

...inery detect this case and break up the glue, for instance via breaking up (adde X, Y, Carry) into (add (add X, Y)n (adde 0, 0, Carry)) or something alike when the situation present itself. 3/ Do whatever the X86 backend does, which I'm not sure what it is. Advice ? Thanks in advance, Amaury SECHET -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170207/6808301d/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: dagisel.png Type: image/png Size: 2...

...? Because if not, that's a big problem. It looks like the problem is that the compiler now choose to use pushfq/popfq in some cases rather than chaining adc to propagate the carry in additions. I hope this can get sorted out quickly. I'm happy to help if that is necessary. Thanks, Amaury SECHET -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170225/d4f97afd/attachment.html>

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

...gt; > If that's not feasible, I don't think there's much you can do that is not > effectively preventing one of those transitions from occurring when it > would cause the infinite visit loop. > > HTH, > > -Nirav > > > On Mon, May 22, 2017 at 2:21 AM, Amaury SECHET via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 work...

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

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

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

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 > are not realized as...

...to the A in the acronym. Subsequent code manipulating the DAG to not like it at all. Can you explain me what you were trying to do in that commit ? I know it is several month old, so the answer is likely not in cache, but that is capital to me to understand what is the correct fix. Thank, Amaury SECHET -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140704/1b8fa2b3/attachment.html>

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

...and false for canInsertSelect(), the code would look the way you'd like it to. But as I said, I'm mostly speculating here and I might be very wrong. On Mon, Jan 23, 2017 at 5:02 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Jan 23, 2017, at 4:06 AM, Amaury SECHET via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > Some non trivial legalization of operations which aren't supported by > the backend would benefit from having the optimizer pass on them. I noticed > some example trying to optimiz...

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

...looks to be the case here. > > I'm going to leave this for a little while longer to get a check that all > the buildbots pass, but I'll revert this and make sure this test case looks > more reasonable. > > -Nirav > > > > On Sat, Feb 25, 2017 at 12:51 PM, Amaury SECHET <deadalnix at gmail.com> > wrote: > >> Hi, >> >> I'm working with workload where the bottleneck is cryptographic signature >> checks. Or, in compiler terms, most large integer operations. >> >> Looking at rL296252 , the state of affair in that are...

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