search for: d68150

Displaying 4 results from an estimated 4 matches for "d68150".

2019 Oct 07
2
Shift-by-signext - sext is bad for analysis - ignore it's use count?
...yDemandedBits(). > > I can't pass the Known down the stack, the function resets it first thing, > > so Known can only be passed from callee to the caller. > > > > This is why i'm asking whether anyone is concerned if we proceed with > > https://reviews.llvm.org/D68150 > > > > On Tue, Oct 1, 2019 at 10:44 PM Nikita Popov <nikita.ppv at gmail.com> wrote: > > > > > > On Tue, Oct 1, 2019 at 8:57 PM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> > > >> Thanks for taking a look! &...
2019 Oct 01
2
Shift-by-signext - sext is bad for analysis - ignore it's use count?
...nd i'm not sure how to convey that to SimplifyDemandedBits(). I can't pass the Known down the stack, the function resets it first thing, so Known can only be passed from callee to the caller. This is why i'm asking whether anyone is concerned if we proceed with https://reviews.llvm.org/D68150 On Tue, Oct 1, 2019 at 10:44 PM Nikita Popov <nikita.ppv at gmail.com> wrote: > > On Tue, Oct 1, 2019 at 8:57 PM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Thanks for taking a look! >> >> On Tue, Oct 1, 2019 at 9:09 PM Philip Ream...
2019 Sep 27
2
Shift-by-signext - sext is bad for analysis - ignore it's use count?
...1686130 Sanjay Patel notes that this sext is intrusive for analysis, that we will gain far better analysis with zext, so we should just ignore forego of the one-use check, and simply replace all shift-by-sext with shift-by-zext. I implemented this proposed suggestion here: https://reviews.llvm.org/D68150 Does anyone see any problems with that trade-off? Roman.
2019 Oct 01
2
Shift-by-signext - sext is bad for analysis - ignore it's use count?
...> produce the duplicate nodes, and rely on later CSE. I keep running > across cases where we have an extend where we know the high bits don't > matter, maybe it's time to represent that? > > > I implemented this proposed suggestion here: > > https://reviews.llvm.org/D68150 > > > > Does anyone see any problems with that trade-off? > > Roman. > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev