On Feb 26, 2012, Richard Sandiford wrote:
> It seemed that when we recorded two values V1 and V2 were equivalent,
> we added V1 to V2's location list and V2 to V1's location list. But
> it sounds from the above like the canonical value is what we want in
> almost all cases, so if V2 is the one t
Alexandre Oliva writes:
> On Feb 19, 2012, Richard Sandiford wrote:
>> and it still isn't obvious to me when canonical_cselib_val is supposed
>> to be used.
>
> For comparison of VALUEs, it avoids the need for recursive or
> combinatorial compares, for all equivalent VALUEs map directly to the
>
On Feb 19, 2012, Richard Sandiford wrote:
> I have to admit I still don't like these changes
> I'd much rather we kept to the original dag.
I'm not sure I mentioned before, but it remains a DAG unless
cselib_add_permanent_equiv is called. Only var-tracking calls it, and
even then, only when VTA
On Fri, Feb 17, 2012 at 02:01:36AM -0200, Alexandre Oliva wrote:
> for gcc/ChangeLog
> from Alexandre Oliva
>
> PR debug/52001
> * cselib.c (preserve_only_constants): Rename to...
> (preserve_constants_and_equivs): ... this. Split out...
> (invariant_or_equiv_p): ... th
Alexandre Oliva writes:
> On Feb 15, 2012, Richard Sandiford wrote:
>
>> I'm fine with putting it in and seeing what breaks. But I'd really
>> prefer if we knew in theory. :-)
>
> Ok, I dove into the problem without a testcase, and I managed to trigger
> it on other platforms after tweaking get_
On Feb 15, 2012, Richard Sandiford wrote:
> I'm fine with putting it in and seeing what breaks. But I'd really
> prefer if we knew in theory. :-)
Ok, I dove into the problem without a testcase, and I managed to trigger
it on other platforms after tweaking get_addr a bit so as use loc lists
form
Alexandre Oliva writes:
> On Feb 13, 2012, Richard Sandiford wrote:
>> does this avoid the kind of memrefs_conflict_p cycle I was seeing in:
>
> I don't know that it does, I'd missed that bit.
>
> If you still have a preprocessed testcase, I'd be glad to give it a
> quick try. Failing that, I ca
On Feb 13, 2012, Jakub Jelinek wrote:
> I'm not convinced you want the
>> + /* Keep VALUE equivalences around. */
>> + for (l = v->locs; l; l = l->next)
>> +if (GET_CODE (l->loc) == VALUE)
>> + return true;
> hunk in invariant_p,
Yeah, maybe “invariant_p” is a misnomer. The thinking
On Feb 13, 2012, Richard Sandiford wrote:
> does this avoid the kind of memrefs_conflict_p cycle I was seeing in:
I don't know that it does, I'd missed that bit.
If you still have a preprocessed testcase, I'd be glad to give it a
quick try. Failing that, I can try a build on my yeeloong, but..
Alexandre Oliva writes:
> Jakub asked to have a closer look at the problem, and I found we could
> do somewhat better. The first thing I noticed was that the problem was
> that, in each block that computed a (base+const), we created a new VALUE
> for the expression (with the same const and global
On Mon, Feb 13, 2012 at 12:27:35PM -0200, Alexandre Oliva wrote:
> Jakub asked to have a closer look at the problem, and I found we could
> do somewhat better. The first thing I noticed was that the problem was
> that, in each block that computed a (base+const), we created a new VALUE
> for the ex
Jakub asked to have a closer look at the problem, and I found we could
do somewhat better. The first thing I noticed was that the problem was
that, in each block that computed a (base+const), we created a new VALUE
for the expression (with the same const and global base), and a new
reverse operati
12 matches
Mail list logo
