-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aldy Hernandez wrote:
> How does this look?
>
I think I'd rather fix DCE/DSE independently of SFTs. Excessive
reliance on the pseudo scalarization given by SFTs brings problems of
its own.
We could explore that idea we talked about before where we
On 4/18/06, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
> > losing a slight missed optimization on the tree level.
>
> Yay, exactly what I'm trying to fix. Glad you agree.
You can try disabling the write_only heuristic completely on mem-ssa branch
and see if you get huge regressions on the compile
> losing a slight missed optimization on the tree level.
Yay, exactly what I'm trying to fix. Glad you agree.
Aldy
>
> > Well, it's written to only in this testcase. Can you post a more complete
> > one?
>
> Here's the complete testcase.
>
> int g(_Complex int*);
> int f(void)
> {
> _Complex int t = 0;
> __real__ t = 2;
> __imag__ t = 2;
> return g(&t);
> }
Yes but that should not matter always as th
> Well, it's written to only in this testcase. Can you post a more complete
> one?
Here's the complete testcase.
int g(_Complex int*);
int f(void)
{
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
return g(&t);
}
> I should also mention on the mainline, we get the decomposing for the
> orginal testcase which means this is a bug only on the MEM-SSA branch.
No we don't. Look at the actual testcase I posted. This is a bug on
mainline.
>
> >
> > Hi folks.
> >
> > While investigating a regression from the V_MUST_DEF removal on mem-ssa,
> > I've noticed that we were missing out on optimization of certain
> > stores to complex types (on mainline).
> >
> > For example, here:
> >
> > _Complex int t = 0;
> > __real__ t = 2;
> >
>
> Hi folks.
>
> While investigating a regression from the V_MUST_DEF removal on mem-ssa,
> I've noticed that we were missing out on optimization of certain
> stores to complex types (on mainline).
>
> For example, here:
>
> _Complex int t = 0;
> __real__ t = 2;
> __imag__ t = 2;
>
> we e
On 4/17/06, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
> Hi folks.
>
> While investigating a regression from the V_MUST_DEF removal on mem-ssa,
> I've noticed that we were missing out on optimization of certain
> stores to complex types (on mainline).
>
> For example, here:
>
> _Complex int t = 0;
> I see the original rationale for inhibiting creation of subvariables
> on aggregates here:
>
> http://gcc.gnu.org/ml/fortran/2006-01/msg00195.html
>
> But I don't think, memory wise, it should apply to complex types.
> This patch will cause the clearring of "t" to be redundant on mainline.
> On
Hi folks.
While investigating a regression from the V_MUST_DEF removal on mem-ssa,
I've noticed that we were missing out on optimization of certain
stores to complex types (on mainline).
For example, here:
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
we end up with:
# t_2 = V_MU
11 matches
Mail list logo
