Displaying 3 results from an estimated 3 matches for "enableatomictidy".
2014 Oct 14
3
[LLVMdev] RFC: Should we have (something like) -extra-vectorizer-passes in -O2?
...h I sent for review recently: the pass is rather
expensive because it relies on several analysis passes, and is only useful
if AtomicExpand introduced fences. Being able to say "Only run this pass if
the code was modified by this previous pass" would be awesome.
Yet another example is the EnableAtomicTidy flag on ARM that runs
simplifyCFG after AtomicExpand to cleanup some of the
load-linked/store-conditional loops: if no such loops have been introduced,
the cleanup is unnecessary.
On Tue, Oct 14, 2014 at 12:24 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>...
2014 Oct 14
2
[LLVMdev] RFC: Should we have (something like) -extra-vectorizer-passes in -O2?
...tly:
> the pass is rather expensive because it relies on several analysis
> passes, and is only useful if AtomicExpand introduced fences. Being
> able to say "Only run this pass if the code was modified by this
> previous pass" would be awesome.
> Yet another example is the EnableAtomicTidy flag on ARM that runs
> simplifyCFG after AtomicExpand to cleanup some of the
> load-linked/store-conditional loops: if no such loops have been
> introduced, the cleanup is unnecessary.
>
>
>
>
> On Tue, Oct 14, 2014 at 12:24 PM, Hal Finkel < hfinkel at anl.gov >
&...
2014 Oct 14
4
[LLVMdev] RFC: Should we have (something like) -extra-vectorizer-passes in -O2?
I’ll summarize your responses as: The new pipeline produces better results than the old, and we currently have no good mechanism for reducing the compile time overhead.
I’ll summarize my criticism as: In principle, there are better ways to clean up after the vectorizer without turning it into a complicated megapass, but no one has done the engineering. I don’t think cleaning up after the