search for: niravd

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

...ld 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é <niravd at google.com>: > This is a little hard to diagnose in the abstract, but it sounds like > you're having a loop along the lines of visit A -> visit B/C -> visit D -> > visit A and that at each step you're making a real reasonable change to the > DAG and returning to...

On Wed, Jun 22, 2016 at 6:05 AM Nirav Davé <niravd at google.com> wrote: > This appears to work: > > auto Target = OutContext.createLinkerPrivateTempSymbol(); > > with > > auto Target = OutContext.createTempSymbol(); > > -Nirav > > Thanks Nirav -- I tried this but I'm still getting a "jmpq <address&g...

...s between v5.0 and v6.0 have introduced this DAG reduction dependency loop. Is there any advice to Out-of-Tree implementations about how to re-write their lowering code for shuffle so as to avoid this kind of infinite dependency coupling? Thanks, MartinO From: Nirav Davé [mailto:niravd at google.com] Sent: 01 March 2018 20:45 To: MartinO at theheart.ie Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Heap Exhaustion during 'DAGCombiner::Run' Martin: I suspect this is an issue with post-DAG legalization store merging in the DAGCombiner. If y...

...address is resolved and erroneously applies branch relaxation to the jump. I don't know why a linker private symbol would make a difference. -Nirav On Wed, Jun 22, 2016 at 12:14 PM, Dean Michael Berris <dberris at google.com> wrote: > On Wed, Jun 22, 2016 at 6:05 AM Nirav Davé <niravd at google.com> wrote: > >> This appears to work: >> >> auto Target = OutContext.createLinkerPrivateTempSymbol(); >> >> with >> >> auto Target = OutContext.createTempSymbol(); >> >> -Nirav >> >> > Thanks Nirav -- I tried this...

...ked at this a bit, I think you're right that the jumps are being relaxed, due to the -mrelax-all option being used by clang. The question becomes whether it's possible to inhibit relaxation for specific instructions at the LLVM level. Cheers On Wed, Jun 22, 2016 at 9:37 AM Nirav Davé <niravd at google.com> wrote: > Hmm. Odd. I just rebuilt from scratch and it seems to work with > the test/CodeGen/X86/xray-attribute-instrumentation.ll test case outputing > straight to obj: > > llc -filetype=obj -o ~/a.o -mtriple=x86_64-apple-macosx < > test/CodeGen/X86/xray-a...

Martin: I suspect this is an issue with post-DAG legalization store merging in the DAGCombiner. If you have a custom lowered type the DAGCombiner may end up merging a set of stores and immediately splitting them up in legalization. You should be able to disable this pass universally by overriding mergeStoresAfterLegalization() or conditionally for cases that shouldn't match with

...> > > > Is there any advice to Out-of-Tree implementations about how to re-write > their lowering code for shuffle so as to avoid this kind of infinite > dependency coupling? > > > > Thanks, > > > > MartinO > > > > *From:* Nirav Davé [mailto:niravd at google.com] > *Sent:* 01 March 2018 20:45 > *To:* MartinO at theheart.ie > *Cc:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] Heap Exhaustion during 'DAGCombiner::Run' > > > > Martin: > > > > I suspect this is an issue with p...

Hi LLVM-Devs, I am in the process of updating our out-of-tree implementation from v5.0 to v6.0 RC3, and while it builds and mostly runs, I am having trouble with a small number of tests where the 'WorklistMap' in 'DAGCombiner::Run' never becomes empty. This is resulting in a runaway state of continuous heap allocation until the process exhausts all system memory. But I can't

...right that the jumps are being > relaxed, due to the -mrelax-all option being used by clang. The question > becomes whether it's possible to inhibit relaxation for specific > instructions at the LLVM level. > > Cheers > > > On Wed, Jun 22, 2016 at 9:37 AM Nirav Davé <niravd at google.com> wrote: > >> Hmm. Odd. I just rebuilt from scratch and it seems to work with >> the test/CodeGen/X86/xray-attribute-instrumentation.ll test case outputing >> straight to obj: >> >> llc -filetype=obj -o ~/a.o -mtriple=x86_64-apple-macosx < >...

...-line option, and as I’ve said it doesn’t help because it’s a non-local interval causing the eviction chain (RAGreedy::splitCanCauseEvictionChain only considers the local interval for a single block, and it’s unclear to me how to make it handle a non-local interval). John From: Nirav Davé [mailto:niravd at google.com] Sent: 05 December 2018 17:14 To: John Brawn Cc: llvm-dev; nd Subject: Re: [llvm-dev] Strange regalloc behaviour: one more available register causes much worse allocation This has cropped up before in X86 (https://bugs.llvm.org/show_bug.cgi?id=26810 / https://reviews.llvm.org/rL31629...

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 have a bit of a riddle: In http://reviews.llvm.org/D19904 I'm trying to spell the following assembly: .palign 2, 0x90 jmp +0x9 nopw 512(%rax,%rax,1) // rest of the code I try the following snippet to accomplish this: OutStreamer->EmitLabel(CurSled); OutStreamer->EmitCodeAlignment(4); auto Target = OutContext.createLinkerPrivateTempSymbol(); // Use a two-byte `jmp`.

Preamble -------- While working on an IR-level optimisation completely unrelated to register allocation I happened to trigger some really strange register allocator behaviour causing a large regression in bzip2 in spec2006. I've been trying to fix that regression before getting the optimisation patch committed, because I don't want to regress spec2006, but I'm basically fumbling in