Mark &mut pointers as noalias once LLVM no longer miscompiles them #31681

bstrie · 2016-02-15T17:59:52Z

This issue tracks the undoing of the workaround introduced in #31545 on account of a bug in LLVM. cc @dotdash

jplatte · 2016-02-18T01:17:13Z

Was just reading about this, and it was a little hard to find the LLVM bug report, so for reference, here it is.

eefriedman · 2016-05-31T21:27:04Z

I've been working through the LLVM optimization passes to find noalias-related bugs. Known issues:

~~https://bugs.llvm.org/show_bug.cgi?id=25422~~ Fixed
~~https://bugs.llvm.org/show_bug.cgi?id=27849~~ Fixed
~~https://bugs.llvm.org/show_bug.cgi?id=27857~~ Fixed
~~https://bugs.llvm.org/show_bug.cgi?id=27858~~ Fixed
~~https://bugs.llvm.org/show_bug.cgi?id=27859~~ Fixed
~~https://bugs.llvm.org/show_bug.cgi?id=27860~~ Fixed
~~https://bugs.llvm.org/show_bug.cgi?id=27952~~ Fixed
~~https://bugs.llvm.org/show_bug.cgi?id=27953~~ Fixed

Some of these are less important because they can't caused a wrong value, only a segfault.

There are probably a few more lurking issues, but hopefully I've found most of them.

(Edited by bluss 2016-12-15 to strike out fixed bug)
(Edited by mbrubeck 2017-03-30 to link to new LLVM bugzilla domain)
(Edited by scottmcm 2018-03-29 to strike out fixed bug)

mrhota · 2016-08-06T00:50:05Z

@eefriedman LLVM bug 27859 is closed.

…with_element Due to missing noalias annotations for &mut T in general (issue rust-lang#31681), in larger programs extend_from_slice and extend_with_element may both compile very poorly. What is observed is that the .set_len() calls are not lifted out of the loop, even for `Vec<u8>`. Use a local length variable for the Vec length instead, and use a scope guard to write this value back to self.len when the scope ends or on panic. Then the alias analysis is easy. This affects extend_from_slice, extend_with_element, the vec![x; n] macro, Write impls for Vec<u8>, BufWriter, etc (but may / may not have triggered since inlining can be enough for the compiler to get it right).

…d, r=alexcrichton Work around pointer aliasing issue in Vec::extend_from_slice, extend_with_element Due to missing noalias annotations for &mut T in general (issue #31681), in larger programs extend_from_slice and extend_with_element may both compile very poorly. What is observed is that the .set_len() calls are not lifted out of the loop, even for `Vec<u8>`. Use a local length variable for the Vec length instead, and use a scope guard to write this value back to self.len when the scope ends or on panic. Then the alias analysis is easy. This affects extend_from_slice, extend_with_element, the vec![x; n] macro, Write impls for Vec<u8>, BufWriter, etc (but may / may not have triggered since inlining can be enough for the compiler to get it right). Fixes #32155 Fixes #33518 Closes #17844

gnzlbg · 2016-09-15T15:12:39Z

@eefriedman bug 25422 should be fixed.

Any progress on bug 27860 ?

(Edited by mbrubeck 2017-03-30 to link to new LLVM bugzilla domain)

pmarcelll · 2017-01-16T10:29:36Z

NewGVN was recently merged into LLVM (still experimental), it's a rewrite of the global value numbering algorithm. The last remaining bug on our list is bug in the old gvn implementation. I compiled the example codes in the bug report with the new gvn algorithm, and they work fine, so hopefully LLVM 5.0 will stabilize NewGVN and we can turn this optimization back on.
EDIT: NewGVN integration into LLVM tracked here

jrmuizel · 2017-07-20T21:08:47Z

I talked with Davide Italiano from LLVM and the goal is for NewGVN to be turned on in LLVM 6.0.
Given that and the fact that https://bugs.llvm.org//show_bug.cgi?id=27860 also affects code that doesn't use restrict/noalias I wonder if we could try turning this on? Even if we could only use this when compiling in panic=abort mode (as it seems many of the codegen issues were related to exceptions).

#42047 is a reduced test case of a real performance problem that's helped by this that we're running into with WebRender so it would be nice to fix this sooner rather than later.

eira-fransham · 2017-08-02T07:18:30Z

I support enabling this if and only if panic = "abort". Even if having the codegen be different depending on panic mode is not currently supported it would be something deserving of an RFC in my opinion, since there are a bunch of possible optimisations that this could enable, like removing zeroing when initialising an array.

Maybe if "treat function calls as possible branch point" is a function-level annotation in LLVM the only difference would be emitting/not emitting that.

jrmuizel · 2017-08-04T15:06:40Z

Is it possible for us to get a cargobomb run with the patch reverted to see if we trigger any bad codegen?

dpc · 2017-08-05T22:18:47Z

Any best guesses when this improvement would be available in Rust nightly (with and without panic = "abort")? It would affect the design and implementation of performance critical crates I'm working on. If it's couple of months, it might be worth waiting. If it's a year, it might be worth to workaround in the code.

arielb1 · 2017-08-06T08:26:30Z

@eefriedman

Is PR27860 actually a problem for Rust? I think every time we emit noalias we also emit dereferencable. Unless LLVM considers every GEP of the pointer as dereferencable, even in the presence of e.g. bounds checks (oops).

oyvindln · 2017-08-09T10:34:38Z

I support enabling this if and only if panic = "abort".

Maybe a -Z enable-noalias or similar option could be added as a start to make it easier to test where the lack of noalias makes a difference.

matthiaskrgr · 2017-09-15T17:43:32Z

@oyvindln if you want to turn on newgvn to compare things, RUSTFLAGS="-C llvm-args=-enable-newgvn" might work.

pcwalton · 2017-09-28T16:24:59Z

It's unclear from reading this what the state of this bug is. Do we still believe that NewGVN will fix this issue?

arielb1 · 2017-09-28T20:44:16Z

@pcwalton

I think all "noalias-exclusive" bugs are fixed, so it might be worth giving it a try and opening a PR.

cuviper · 2017-09-28T20:54:11Z

Does that enablement need to be conditional on LLVM version?

arielb1 · 2017-09-28T20:54:37Z

I think. 4.0 should be fine.

bstrie · 2017-10-20T19:15:39Z

Update: there's now a -Z flag for opting-in to this on an experimental basis: #45012. It also seems as though the behavior is enabled by default for panic=abort builds. However, I think this might be worth keeping open until we concretely determine whether or not we'll be able to turn this on for panic=unwind builds (see #45029 ).

alexbool · 2018-02-11T12:26:25Z

What's the state of this given that LLVM has been upgraded to 6.0?

scottmcm · 2018-03-03T03:13:53Z

To help finding this issue: the -Z flag is mutable_noalias.

scottmcm · 2018-03-30T05:08:43Z

Looks like the last part of the checklist above landed with https://reviews.llvm.org/D38619#937247

nox · 2018-04-02T11:26:01Z

Should we make a PR to always enable mutable_noalias and see what happens on the CI and Crater?

Cc @rust-lang/wg-codegen

This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However, according to rust-lang#31681 all known LLVM bugs have been fixed by LLVM 6.0, so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.

Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However, according to #31681 all known LLVM bugs have been fixed by LLVM 6.0, so it's probably time to reenable this optimization. -Z no-mutable-noalias is left as an escape-hatch to debug problems suspected to stem from this change.

nikic · 2018-05-21T14:34:03Z

As #50744 has landed, this can be closed.

alexcrichton · 2018-05-21T14:48:24Z

🎉

bstrie added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-codegen Area: Code generation A-optimization labels Feb 15, 2016

eefriedman mentioned this issue May 9, 2016

Performance issue in write_all (Vec::extend_from_slice) #33518

Closed

bluss mentioned this issue Sep 8, 2016

Work around pointer aliasing issue in Vec::extend_from_slice, extend_with_element #36355

Merged

bluss mentioned this issue Oct 12, 2016

Unnecessary conditional branch generated #37114

Closed

bluss mentioned this issue Jan 9, 2017

Missed optimization: references from pointers aren't treated as noalias #38941

Open

jrmuizel mentioned this issue May 1, 2017

Arithmetic not folded #41631

Closed

Mark-Simulacrum removed the A-optimization label Jun 23, 2017

jrmuizel mentioned this issue Jul 20, 2017

WebRender has a bad time with https://jrmuizel.github.io/perf-tests/moving-balls.html servo/webrender#1501

Closed

Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 24, 2017

kennytm mentioned this issue Aug 5, 2017

Performance: fails to inline struct field access and keep it in the register. #43653

Closed

durka mentioned this issue Aug 6, 2017

Full name display breaks on comments edited by someone else refined-github/refined-github#656

Closed

arielb1 reopened this Aug 9, 2017

bstrie added the I-slow Issue: Problems and improvements with respect to performance of generated code. label Sep 15, 2017

steveklabnik mentioned this issue Sep 30, 2017

make use of LLVM's scoped noalias metadata #16515

Open

dotdash mentioned this issue Nov 29, 2017

Unnecessary memcpy during struct initialization #45663

Closed

RalfJung mentioned this issue May 14, 2018

mutable noalias: re-enable permanently, only for panic=abort, or stabilize flag? #45029

Closed

nikic mentioned this issue May 14, 2018

Emit noalias on &mut parameters by default #50744

Merged

alexcrichton closed this as completed May 21, 2018

HadrienG2 mentioned this issue Sep 22, 2018

Chasing an UB-smelling bug related to swap_rows dimforge/nalgebra#396

Closed

bstrie mentioned this issue Oct 6, 2018

Enable noalias annotations #54878

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mark &mut pointers as noalias once LLVM no longer miscompiles them #31681

Mark &mut pointers as noalias once LLVM no longer miscompiles them #31681

bstrie commented Feb 15, 2016

jplatte commented Feb 18, 2016

eefriedman commented May 31, 2016 •

edited by scottmcm

Loading

mrhota commented Aug 6, 2016

gnzlbg commented Sep 15, 2016 •

edited by mbrubeck

Loading

pmarcelll commented Jan 16, 2017 •

edited by mbrubeck

Loading

jrmuizel commented Jul 20, 2017

eira-fransham commented Aug 2, 2017 •

edited

Loading

jrmuizel commented Aug 4, 2017

dpc commented Aug 5, 2017

arielb1 commented Aug 6, 2017 •

edited

Loading

oyvindln commented Aug 9, 2017 •

edited

Loading

matthiaskrgr commented Sep 15, 2017

pcwalton commented Sep 28, 2017

arielb1 commented Sep 28, 2017

cuviper commented Sep 28, 2017

arielb1 commented Sep 28, 2017

bstrie commented Oct 20, 2017

alexbool commented Feb 11, 2018

scottmcm commented Mar 3, 2018

scottmcm commented Mar 30, 2018

nox commented Apr 2, 2018

nikic commented May 21, 2018

alexcrichton commented May 21, 2018

Mark &mut pointers as noalias once LLVM no longer miscompiles them #31681

Mark &mut pointers as noalias once LLVM no longer miscompiles them #31681

Comments

bstrie commented Feb 15, 2016

jplatte commented Feb 18, 2016

eefriedman commented May 31, 2016 • edited by scottmcm Loading

mrhota commented Aug 6, 2016

gnzlbg commented Sep 15, 2016 • edited by mbrubeck Loading

pmarcelll commented Jan 16, 2017 • edited by mbrubeck Loading

jrmuizel commented Jul 20, 2017

eira-fransham commented Aug 2, 2017 • edited Loading

jrmuizel commented Aug 4, 2017

dpc commented Aug 5, 2017

arielb1 commented Aug 6, 2017 • edited Loading

oyvindln commented Aug 9, 2017 • edited Loading

matthiaskrgr commented Sep 15, 2017

pcwalton commented Sep 28, 2017

arielb1 commented Sep 28, 2017

cuviper commented Sep 28, 2017

arielb1 commented Sep 28, 2017

bstrie commented Oct 20, 2017

alexbool commented Feb 11, 2018

scottmcm commented Mar 3, 2018

scottmcm commented Mar 30, 2018

nox commented Apr 2, 2018

nikic commented May 21, 2018

alexcrichton commented May 21, 2018

eefriedman commented May 31, 2016 •

edited by scottmcm

Loading

gnzlbg commented Sep 15, 2016 •

edited by mbrubeck

Loading

pmarcelll commented Jan 16, 2017 •

edited by mbrubeck

Loading

eira-fransham commented Aug 2, 2017 •

edited

Loading

arielb1 commented Aug 6, 2017 •

edited

Loading

oyvindln commented Aug 9, 2017 •

edited

Loading