Displaying 20 results from an estimated 12000 matches similar to: "SCCP is not always correct in presence of undef (+ proposed fix)"
2016 Dec 31
0
SCCP is not always correct in presence of undef (+ proposed fix)
Hi David,
Looking at the original bug, it seems like a straightforward
undef-propagation bug to me -- SCCP was folding "or undef, constant"
to "undef", which is wrong. Why is changing that not the fix? That
is, some variant of
diff --git a/lib/Transforms/Scalar/SCCP.cpp b/lib/Transforms/Scalar/SCCP.cpp
index 8a6be97..45f1241 100644
--- a/lib/Transforms/Scalar/SCCP.cpp
+++
2016 Dec 31
4
SCCP is not always correct in presence of undef (+ proposed fix)
On Fri, Dec 30, 2016, 9:04 PM Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi David,
>
> Looking at the original bug, it seems like a straightforward
> undef-propagation bug to me -- SCCP was folding "or undef, constant"
> to "undef", which is wrong. Why is changing that not the fix? That
> is, some variant of
>
You would still
2016 Dec 31
0
SCCP is not always correct in presence of undef (+ proposed fix)
Hi,
On Fri, Dec 30, 2016 at 9:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
> On Fri, Dec 30, 2016, 9:04 PM Sanjoy Das via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi David,
>>
>> Looking at the original bug, it seems like a straightforward
>> undef-propagation bug to me -- SCCP was folding "or undef, constant"
2016 Dec 31
0
SCCP is not always correct in presence of undef (+ proposed fix)
On Fri, Dec 30, 2016 at 9:27 AM, Davide Italiano via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi.
> I'm sending this email to -dev as this may be of interest of
> many/people may have opinions/want to try the change before it goes in
> to report problems.
> I've been recently working on a patch to integrate `undef` in the SCCP
> solver, in the hope of fixing
2016 Dec 31
0
SCCP is not always correct in presence of undef (+ proposed fix)
On Fri, Dec 30, 2016 at 11:55 PM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:
> Hi Daniel,
>
> On Fri, Dec 30, 2016 at 10:55 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> >> Right, but we are talking about "when, in the intermediate state, can i
> >> transform an undef to a different value".
> >>
> >>
2016 Dec 31
2
SCCP is not always correct in presence of undef (+ proposed fix)
On Sat, Dec 31, 2016 at 12:15 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
> On Fri, Dec 30, 2016 at 11:55 PM, Sanjoy Das
> <sanjoy at playingwithpointers.com> wrote:
>>
>> Hi Daniel,
>>
>> On Fri, Dec 30, 2016 at 10:55 PM, Daniel Berlin <dberlin at dberlin.org>
>> wrote:
>> >> Right, but we are talking about
2006 May 10
0
[LLVMdev] SCCP
On Wed, 10 May 2006, Nick Lewycky wrote:
>> Then just run the SCCP pass, and check to see if any operands satisfy
>> the predicate "isa<UndefValue>(V)". LLVM explicitly represents
>> undefined values.
>
> I have a case where it doesn't, but perhaps the SCCP pass isn't to blame:
>
> extern void write_char(int);
>
> const char foo[4] =
2006 May 10
2
[LLVMdev] SCCP
Chris Lattner wrote:
> On Tue, 9 May 2006, Nick Lewycky wrote:
>
>>> You could do that, but SCCPSolver isn't really useful to mainline LLVM
>>> for anything other than SCCP and IPSCCP, so we don't need it in a public
>>> header. Out of curiosity, what are you looking to use the latice values
>>> for? Why not just run SCCP and then look at the
2016 Dec 31
2
SCCP is not always correct in presence of undef (+ proposed fix)
Hi Daniel,
On Fri, Dec 30, 2016 at 10:55 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>> Right, but we are talking about "when, in the intermediate state, can i
>> transform an undef to a different value".
>>
>> Remember you can only go down the lattice. So you can't make undef
>> constant, and then discover it's wrong, and go back up :)
2016 Dec 31
2
SCCP is not always correct in presence of undef (+ proposed fix)
>
>
> >
> > You need to distinguish between not visited and visited but undef.
>
> What I'm getting at is, if you're implementing something close to the
> paper mentioned, I can't think of a case where you'd care to
> distinguish between "not visited" and "visited but undef". That is,
> instead of starting from "map each
2016 Dec 31
0
SCCP is not always correct in presence of undef (+ proposed fix)
>
>
> Is there a case in your algorithm in which treating an
>> unknown as an undef will be a problem?
>>
>> Yes, if you try to optimize undefs in any way, no if you move them to
overdefined :)
IE given phi [a, undef, undef, undef]
with just as many back edges, you will visit this node 4 times.
If you start out with
phi [a, undef, undef, undef], you may think
2006 May 10
2
[LLVMdev] SCCP
Chris Lattner wrote:
> On Tue, 9 May 2006, Nick Lewycky wrote:
>
>>>> For an analysis pass, I'm interested in reading the lattice values
>>>> calculated by SCCP. Should I split the current SCCP optimization
>>>> into an
>>>> analysis piece and the optimization that depends on it, so that I can
>>>> use its analysis results?
2016 Dec 31
0
SCCP is not always correct in presence of undef (+ proposed fix)
Hi Daniel,
On Fri, Dec 30, 2016 at 9:47 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>
>>> Is there a case in your algorithm in which treating an
>>> unknown as an undef will be a problem?
>>>
> Yes, if you try to optimize undefs in any way, no if you move them to
> overdefined :)
>
> IE given phi [a, undef, undef, undef]
>
> with
2017 Jan 02
2
SCCP is not always correct in presence of undef (+ proposed fix)
On Mon, Jan 2, 2017 at 2:24 PM, Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
> Hi Davide,
>
> On Sat, Dec 31, 2016 at 4:19 AM, Davide Italiano <davide at freebsd.org> wrote:
>> Although originally I wasn't, I'm increasingly convinced this is the
>> right path forward (at least in the beginning), i.e. strip undef
>> handling entirely. I tried
2006 May 10
2
[LLVMdev] SCCP
Chris Lattner wrote:
> On Wed, 10 May 2006, Nick Lewycky wrote:
>
>>> Then just run the SCCP pass, and check to see if any operands satisfy
>>> the predicate "isa<UndefValue>(V)". LLVM explicitly represents
>>> undefined values.
>>
>>
>> I have a case where it doesn't, but perhaps the SCCP pass isn't to blame:
>>
2016 Dec 31
2
SCCP is not always correct in presence of undef (+ proposed fix)
On Fri, Dec 30, 2016 at 10:01 PM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:
> Hi Daniel,
>
> On Fri, Dec 30, 2016 at 9:47 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> >>
> >>> Is there a case in your algorithm in which treating an
> >>> unknown as an undef will be a problem?
> >>>
> > Yes, if you
2006 May 10
0
[LLVMdev] SCCP
On Tue, 9 May 2006, Nick Lewycky wrote:
>> You could do that, but SCCPSolver isn't really useful to mainline LLVM
>> for anything other than SCCP and IPSCCP, so we don't need it in a public
>> header. Out of curiosity, what are you looking to use the latice values
>> for? Why not just run SCCP and then look at the transformed code?
>
> I was planning to
2016 Dec 31
0
SCCP is not always correct in presence of undef (+ proposed fix)
On Fri, Dec 30, 2016 at 10:54 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
> On Fri, Dec 30, 2016 at 10:01 PM, Sanjoy Das <sanjoy at playingwithpointers.
> com> wrote:
>
>> Hi Daniel,
>>
>> On Fri, Dec 30, 2016 at 9:47 PM, Daniel Berlin <dberlin at dberlin.org>
>> wrote:
>> >>
>> >>> Is there a case in
2016 Aug 24
2
LLVM 3.9 RC2's SCCP pass removing calls to external functions?!
Hi Félix,
Sanjoy Das wrote:
> Félix Cloutier via llvm-dev wrote:
> > Assuming that this is a bug, what are the next steps?
>
> Looks like you already have a very small test case -- have you tried
> sticking it in a debugger to see why SCCP thinks removing the call is
> okay?
>
> Alternatively, file a bug at llvm.org/bugs and someone will get to it.
The third
2006 Jun 05
2
[LLVMdev] SCCP and undef branches
I found that "undef" was disappearing early into the optimization chain.
SCCP was the culprit, transforming:
br bool undef, label %T, label %F
into
br bool true, label %T, label %F
While that sounds like a great optimization, it shouldn't be happening
that early. I've put together a patch which modifies the behaviour of
SCCP so that it preserves undef in those cases.
I