search for: r226781

...ining bitcasts during code gen. Other alternative solutions are welcome. Should I implement the proposed solution or is it too risky? I understand that we may need to undo it if it breaks too many things. Comments are welcome. [1] http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html r226781 git commit id: b778cbc0c8 Code Samples (only relevant part is copied): -------------------- Before Canonicalization (contains call to std::max): -------------------- entry: %max_value = alloca float, align 4 %1 = load float, float* %input, align 4, !tbaa !1 store float %1, float* %max_v...

Hi , The following loop fails to be vectorized since the load c[i] is casted as i64 and the store c[i] is double. The loop access analysis gives up since they are in different types. Since these two memory operations are in the same size, I believe the loop access analysis should return forward dependence and thus the loop can be vectorized. Any comments? Thanks, Jin #define N 1000 double

...alternative solutions are welcome. > > Should I implement the proposed solution or is it too risky? I understand > that we may need to undo it if it breaks too many things. Comments are > welcome. > > > [1] http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html > r226781 git commit id: b778cbc0c8 > > > > Code Samples (only relevant part is copied): > > -------------------- Before Canonicalization (contains call to std::max): > -------------------- > entry: > %max_value = alloca float, align 4 > %1 = load float, float* %input, ali...

...ould I implement the proposed solution or is it too risky? I >>> understand that we may need to undo it if it breaks too many things. >>> Comments are welcome. >>> >>> >>> [1] http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>> r226781 git commit id: b778cbc0c8 >>> >>> >>> >>> Code Samples (only relevant part is copied): >>> >>> -------------------- Before Canonicalization (contains call to >>> std::max): -------------------- >>> entry: >>> %max_...

...posed solution or is it too risky? I >>>> understand that we may need to undo it if it breaks too many things. >>>> Comments are welcome. >>>> >>>> >>>> [1] http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>>> r226781 git commit id: b778cbc0c8 >>>> >>>> >>>> >>>> Code Samples (only relevant part is copied): >>>> >>>> -------------------- Before Canonicalization (contains call to >>>> std::max): -------------------- >>>...

...sed solution or is it too risky? I understand that we may need to undo it if it breaks too many things. Comments are welcome. >> >> >> [1] http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html> r226781 git commit id: b778cbc0c8 >> >> >> >> Code Samples (only relevant part is copied): >> >> -------------------- Before Canonicalization (contains call to std::max): -------------------- >> entry: >> %max_value = alloca float, align 4 >>...

...ings. Comments are welcome. >>>> >>>> >>>> [1] <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html>http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html> r226781 git commit id: b778cbc0c8 >>>> >>>> >>>> >>>> Code Samples (only relevant part is copied): >>>> >>>> -------------------- Before Canonicalization (contains call to std::max): -------------------- >>>> entry:...

...erstand that we may need to undo it >>> if it breaks too many things. Comments are welcome. >>> >>> >>> [1] >>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>> r226781 git commit id: b778cbc0c8 >>> >>> >>> >>> Code Samples (only relevant part is copied): >>> >>> -------------------- Before Canonicalization >>> (contains call to std::max): --------------...

...lestone or sorts. [r226987](http://reviews.llvm.org/rL226987). * LLVM learnt how to use the GHC calling convention on AArch64. [r226473](http://reviews.llvm.org/rL226473). * InstCombine will now canonicalize loads which are only ever stored to always use a legal integer type if one is available. [r226781](http://reviews.llvm.org/rL226781). * The `llvm_any_ty` type for intrinsics has been born. [r226857](http://reviews.llvm.org/rL226857). * llvm-objdump now understands `-indirect-symbols` to dump the Mach-O indirect symbol table. [r226848](http://reviews.llvm.org/rL226848). ## Clang commits * C...

.... Comments >>>>> are welcome. >>>>> >>>>> >>>>> [1] >>>>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>>>> r226781 git commit id: b778cbc0c8 >>>>> >>>>> >>>>> >>>>> Code Samples (only relevant part is copied): >>>>> >>>>> -------------------- Before Canonicalization >>>>...

...gt;> Comments are welcome. >>>>> >>>>> >>>>> [1] >>>>> <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html> >>>>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>>>> r226781 git commit id: b778cbc0c8 >>>>> >>>>> >>>>> >>>>> Code Samples (only relevant part is copied): >>>>> >>>>> -------------------- Before Canonicalization (contains call to >>>>> std::max): -----...

...me. >>>>>> >>>>>> >>>>>> [1] <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html>http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html> r226781 git commit id: b778cbc0c8 >>>>>> >>>>>> >>>>>> >>>>>> Code Samples (only relevant part is copied): >>>>>> >>>>>> -------------------- Before Canonicalization (contains call to std::max)...

...t; > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html > > > > > > > > > r226781 git commit id: b778cbc0c8 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Code Samples (only relevant part is cop...

...s. Comments are welcome. >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>>>>>> r226781 git commit id: b778cbc0c8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Code Samples (only relevant part is copied): >>>>>>> >>>>>>> -------------...

...>>> >>>>>>>> >>>>>>>> [1] <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html>http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html> r226781 git commit id: b778cbc0c8 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Code Samples (only relevant part is copied): >>>>>>>> >>>>>>>> -------------------- Bef...

...come. >>>>>> >>>>>> >>>>>> [1] >>>>>> <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html> >>>>>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>>>>> r226781 git commit id: b778cbc0c8 >>>>>> >>>>>> >>>>>> >>>>>> Code Samples (only relevant part is copied): >>>>>> >>>>>> -------------------- Before Canonicalization (contains call to >>>&...

...t;>> >>>>>>> >>>>>>> [1] >>>>>>> <http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html> >>>>>>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>>>>>> r226781 git commit id: b778cbc0c8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Code Samples (only relevant part is copied): >>>>>>> >>>>>>> -------------------- Before Canonicalization (contai...

...t;>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>>>>>>>> r226781 git commit id: b778cbc0c8 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Code Samples (only relevant part >>>>>>>>>...

...t;>> >>>>>>>>>> [1] >>>>>>>>>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html >>>>>>>>>> r226781 git commit id: >>>>>>>>>> b778cbc0c8 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cod...

Hello all, This is a proposal for reducing # of ptrtoint/inttoptr casts which are not written by programmers but rather generated by LLVM passes. Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, the output IR contains 22,771 inttoptr instructions. However, when compiling it with -O0, there are only 1048