Displaying 13 results from an estimated 13 matches for "loopversioninglicm".
2017 Jul 16
4
PartialAlias: different start addresses
...ients of MustAlias:
> >> ~/llvm/lib/Transforms $ grep -Rl MustAlias .
> >> ./ObjCARC/ObjCARCOpts.cpp
> >> ./ObjCARC/ProvenanceAnalysis.cpp
> >> ./Scalar/DeadStoreElimination.cpp
> >> ./Scalar/GVN.cpp
> >> ./Scalar/LICM.cpp
> >> ./Scalar/LoopVersioningLICM.cpp
> >> ./Scalar/MemCpyOptimizer.cpp
> >> ./Scalar/MergedLoadStoreMotion.cpp
> >> ./Scalar/NewGVN.cpp
> >> ./Utils/VNCoercion.cpp
> >>
> >> I glanced over all the uses in these files and I couldn't find any
> >> usage that requires...
2017 Jul 15
2
PartialAlias: different start addresses
...>>
>> I grepped for clients of MustAlias:
>> ~/llvm/lib/Transforms $ grep -Rl MustAlias .
>> ./ObjCARC/ObjCARCOpts.cpp
>> ./ObjCARC/ProvenanceAnalysis.cpp
>> ./Scalar/DeadStoreElimination.cpp
>> ./Scalar/GVN.cpp
>> ./Scalar/LICM.cpp
>> ./Scalar/LoopVersioningLICM.cpp
>> ./Scalar/MemCpyOptimizer.cpp
>> ./Scalar/MergedLoadStoreMotion.cpp
>> ./Scalar/NewGVN.cpp
>> ./Utils/VNCoercion.cpp
>>
>> I glanced over all the uses in these files and I couldn't find any usage
>> that requires sizes to match. Actually most cli...
2017 Jul 15
2
PartialAlias: different start addresses
...cA.Ptr == LocB.Ptr)
return LocA.Size == LocB.Size ? MustAlias : PartialAlias;
I grepped for clients of MustAlias:
~/llvm/lib/Transforms $ grep -Rl MustAlias .
./ObjCARC/ObjCARCOpts.cpp
./ObjCARC/ProvenanceAnalysis.cpp
./Scalar/DeadStoreElimination.cpp
./Scalar/GVN.cpp
./Scalar/LICM.cpp
./Scalar/LoopVersioningLICM.cpp
./Scalar/MemCpyOptimizer.cpp
./Scalar/MergedLoadStoreMotion.cpp
./Scalar/NewGVN.cpp
./Utils/VNCoercion.cpp
I glanced over all the uses in these files and I couldn't find any usage
that requires sizes to match. Actually most clients check access sizes
themselves. Most don't need equa...
2017 Jul 16
2
PartialAlias: different start addresses
...ib/Transforms $ grep -Rl MustAlias .
>>>>> ./ObjCARC/ObjCARCOpts.cpp
>>>>> ./ObjCARC/ProvenanceAnalysis.cpp
>>>>> ./Scalar/DeadStoreElimination.cpp
>>>>> ./Scalar/GVN.cpp
>>>>> ./Scalar/LICM.cpp
>>>>> ./Scalar/LoopVersioningLICM.cpp
>>>>> ./Scalar/MemCpyOptimizer.cpp
>>>>> ./Scalar/MergedLoadStoreMotion.cpp
>>>>> ./Scalar/NewGVN.cpp
>>>>> ./Utils/VNCoercion.cpp
>>>>>
>>>>> I glanced over all the uses in these files and I couldn't...
2016 Jul 21
2
RFC: Strong GC References in LLVM
...alysis, i'm, again,
> really not sure which passes you are thinking about here that do code
> sinking/speculation that won't need it.
>
> Here's the list definitely needing it right now:
> GVN
> GVNHoist
> LICM
> LoadCombine
> LoopReroll
> LoopUnswitch
> LoopVersioningLICM
> MemCpyOptimizer
> MergedLoadStoreMotion
> Sink
>
> The list is almost certainly larger than this, this was a pretty trivial
> grep and examination.
> (and doesn't take into account bugs, etc)
>
>
(Note, this list is stuff in the Scalar directory only. Everything in...
2016 Jul 21
3
RFC: Strong GC References in LLVM
> On Jul 21, 2016, at 7:45 AM, Philip Reames <listmail at philipreames.com> wrote:
>
> Joining in very late, but the tangent here has been interesting (if rather OT for the original thread).
>
> I agree with Danny that we might want to take a close look at how we model things like maythrow calls, no return, and other implicit control flow. I'm not convinced that moving
2016 Jul 21
4
RFC: Strong GC References in LLVM
...sure which passes you are thinking about here that do code
>> sinking/speculation that won't need it.
>>
>> Here's the list definitely needing it right now:
>> GVN
>> GVNHoist
>> LICM
>> LoadCombine
>> LoopReroll
>> LoopUnswitch
>> LoopVersioningLICM
>> MemCpyOptimizer
>> MergedLoadStoreMotion
>> Sink
>>
>> The list is almost certainly larger than this, this was a pretty trivial
>> grep and examination.
>> (and doesn't take into account bugs, etc)
>>
>>
>
> (Note, this list is stuf...
2020 Jan 11
2
Writing loop transformations on the right representation is more productive
...ions. If the condition
> > fails, the original code is executed.
>
> This sounds like it will bloat code for a lot of cold cases. Or worse,
> get it wrong, and put hot code in the cold path.
Are you arguing against code versioning? It is already done today by
multiple passes such as LoopVersioningLICM, LoopDistribute,
LoopUnrollAndJam and LoopVectorize. The proposal explicitly tries to
avoid code bloat by having just one fallback copy. Runtime conditions
can be chosen more or less optimistically, but I don't see how this
should be an argument for all kinds of versioning.
If you are concerne...
2017 Jul 14
2
PartialAlias: different start addresses
Thank you all for your replies.
So here seems to be an agreement that the documentation for PartialAlias is
incorrect.
Daniel: now you got me wondering about MustAlias. This is what the docs say:
"The MustAlias response may only be returned if the two memory objects are
*guaranteed to always start at exactly the same location*"
This statement is regardless of the access sizes. For
2020 Jan 15
2
Writing loop transformations on the right representation is more productive
...t creating another IR will invariably create
> some adoption barriers.
I see it as an advantage in respect of adoption: It can be switched on and
off without affecting other parts.
> > Are you arguing against code versioning? It is already done today by
> > multiple passes such as LoopVersioningLICM, LoopDistribute,
> > LoopUnrollAndJam and LoopVectorize. The proposal explicitly tries to
> > avoid code bloat by having just one fallback copy. Runtime conditions
> > can be chosen more or less optimistically, but I don't see how this
> > should be an argument for all k...
2017 Oct 13
3
[RFC] Polly Status and Integration
...mpilation and would like to see it used on a
daily basis by just choosing an optimization level.
IMHO we should avoid multiple loop optimizations in LLVM. If each of
them does its own loop versioning, we will get multiple redundant
runtime checks and code duplication. This is already the case with
LoopVersioningLICM, LoopDistribution, LoopVectorizer and
LoopLoadElimination. I argue for a more integrated approach for
loop-based optimizations.
To clarify, what this is not:
- It has not been shown to work in practice.
- While I would like to contribute to implement such a loop optimizer,
this is not something I...
2020 Jan 03
10
Writing loop transformations on the right representation is more productive
In the 2018 LLVM DevMtg [1], I presented some shortcomings of how LLVM
optimizes loops. In summary, the biggest issues are (a) the complexity
of writing a new loop optimization pass (including needing to deal
with a variety of low-level issues, a significant amount of required
boilerplate, the difficulty of analysis preservation, etc.), (b)
independent optimization heuristics and a fixed pass
2017 Sep 01
10
[RFC] Polly Status and Integration
**
*Hi everyone,As you may know, stock LLVM does not provide the kind of
advanced loop transformations necessary to provide good performance on
many applications. LLVM's Polly project provides many of the required
capabilities, including loop transformations such as fission, fusion,
skewing, blocking/tiling, and interchange, all powered by
state-of-the-art dependence analysis. Polly also