search for: instoptimize

Displaying 7 results from an estimated 7 matches for "instoptimize".

2013 Nov 06
3
[LLVMdev] loop vectorizer
...= getelementptr inbounds float* %c, i64 %5 > store float %10, float* %11, align 4, !tbaa !0 > > Honestly, I don't understand why InstCombine "anti-canonicalizes" > add->or. I think that transformation should be deferred into we begin > target-specific lower (e.g. InstOptimize pass). > > Given, that we aren't going to change that any time soon, SCEV could > probably be taught to recognize the specific pattern: > > Instructions (or (and %a, C1), (shl %b, C2)) -> SCEV (add %a, %b) > > -Andy -------------- next part -------------- An HTML atta...
2013 Nov 06
0
[LLVMdev] loop vectorizer
...%5 = or i64 %4, %2 %11 = getelementptr inbounds float* %c, i64 %5 store float %10, float* %11, align 4, !tbaa !0 Honestly, I don't understand why InstCombine "anti-canonicalizes" add->or. I think that transformation should be deferred into we begin target-specific lower (e.g. InstOptimize pass). Given, that we aren't going to change that any time soon, SCEV could probably be taught to recognize the specific pattern: Instructions (or (and %a, C1), (shl %b, C2)) -> SCEV (add %a, %b) -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <htt...
2013 Nov 06
0
[LLVMdev] loop vectorizer
...getelementptr inbounds float* %c, i64 %5 >> store float %10, float* %11, align 4, !tbaa !0 >> >> Honestly, I don't understand why InstCombine "anti-canonicalizes" add->or. I think that transformation should be deferred into we begin target-specific lower (e.g. InstOptimize pass). >> >> Given, that we aren't going to change that any time soon, SCEV could probably be taught to recognize the specific pattern: >> >> Instructions (or (and %a, C1), (shl %b, C2)) -> SCEV (add %a, %b) >> >> -Andy > > > ________________...
2013 Oct 31
5
[LLVMdev] loop vectorizer
On 30 October 2013 18:40, Frank Winter <fwinter at jlab.org> wrote: > const std::uint64_t ir0 = (i+0)%4; // not working > I thought this would be the case when I saw the original expression. Maybe we need to teach module arithmetic to SCEV? --renato -------------- next part -------------- An HTML attachment was scrubbed... URL:
2013 Nov 06
1
[LLVMdev] loop vectorizer
...%5 >>> store float %10, float* %11, align 4, !tbaa !0 >>> >>> Honestly, I don't understand why InstCombine "anti-canonicalizes" >>> add->or. I think that transformation should be deferred into we >>> begin target-specific lower (e.g. InstOptimize pass). >>> >>> Given, that we aren't going to change that any time soon, SCEV could >>> probably be taught to recognize the specific pattern: >>> >>> Instructions (or (and %a, C1), (shl %b, C2)) -> SCEV (add %a, %b) >>> >>> -And...
2013 Jul 17
5
[LLVMdev] IR Passes and TargetTransformInfo: Straw Man
...approximate and relative. They do not represent def-use latencies nor do they distinguish between latency and cpu resources requirements--that level of machine modeling needs to be done in MI passes. IR Lowering Pipeline: Function Passes { Target SimplifyCFG (OptimizeCFG?) Target InstCombine (InstOptimize?) Target Loop Opts { SCEV IndvarSimplify (mainly sxt/zxt elimination) Vectorize/Unroll LSR (move LFTR here too) } SLP Vectorize LowerSwitch CodeGenPrepare } --- The above pass ordering is roughly something I think we can live with. Notice that I have: Full-Unroll ->...
2017 May 19
5
[llvm] r303387 - [InstCombine] add more tests for xor-of-icmps; NFC
[adding llvm-dev for wider audience] On Fri, May 19, 2017 at 12:28 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, May 19, 2017 at 11:00 AM, Davide Italiano <davide at freebsd.org> > wrote: > >> On Fri, May 19, 2017 at 10:00 AM, Sanjay Patel <spatel at rotateright.com> >> wrote: >> > Is "VRP" (value range