On 9/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
>
> > That is exactly what I had in mind. If you invalidate a property then
> > the property is destroyed and whoever asks for it must invoke the
> > relevant function to enable it agai
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 24/09/2007, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > >
> > > And *before* salias? Does it make a difference? It suits me better for
> > > my purposes.
> >
> > Can't do
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> That is exactly what I had in mind. If you invalidate a property then
> the property is destroyed and whoever asks for it must invoke the
> relevant function to enable it again. Is that a problem?
In principle, I don't think that'd be a
On 24/09/2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
>
> > I don't get it. If you ask for PROP_alias and aliases have been
> > computed, then PROP_alias is enabled and you don't need to compute
> > them again.
>
> You do if alias infor
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> I don't get it. If you ask for PROP_alias and aliases have been
> computed, then PROP_alias is enabled and you don't need to compute
> them again.
You do if alias information has gone stale due to transformations.
The SSA form is anothe
On 24/09/2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
>
> > I don't understand is why PROPerties are not associated with TODO_
> > functions in a way that if a pass don't have the properties it
> > requires, it can call the appropriate
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> I don't understand is why PROPerties are not associated with TODO_
> functions in a way that if a pass don't have the properties it
> requires, it can call the appropriate TODO_ function. That way, if
> some pass needs PROP_alias but non
On 24/09/2007, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> >
> > And *before* salias? Does it make a difference? It suits me better for
> > my purposes.
>
> Can't do it before salias.
>
> I didn't want to add a dummy pass mainly because i
On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > > On 9/23/07, Manuel López-Ibáñez <[EMAIL PRO
On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > > On 23 Sep 2007 09:54:29 -0700, Ian Lance Ta
On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> >
> > I am not so concerned about efficiency ATM, I am trying to build SSA at O0.
>
> If you only want simple SSA you should look at doing expansion after
> early optimization.
On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > > On 9/23/07, Manuel López-Ibáñez <[EMAIL PRO
On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Am I wrong? I have the same problem
On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > > On 23 Sep 2007 09:54:29 -0700, Ian Lance Ta
On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > On 23 Sep 2007 09:54:29 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Well, if the -fno-t
On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 23 Sep 2007 09:54:29 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > >
> > > Well, if the -fno-tree-salias flag now causes wrong-code bugs then I
> > > certainly agr
On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 23 Sep 2007 09:54:29 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >
> > Well, if the -fno-tree-salias flag now causes wrong-code bugs then I
> > certainly agree that it should be eliminated.
>
> I didn't say that ;) But I cert
On 23 Sep 2007 09:54:29 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
>
> > > We've got a test case with gcc 4.2 for which compilation time goes
> > > from nine minutes to 30 seconds when we use that option. I know the
> > > code is much better
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> > We've got a test case with gcc 4.2 for which compilation time goes
> > from nine minutes to 30 seconds when we use that option. I know the
> > code is much better in mainline. Still, I would prefer to keep the
> > option unless we are certain th
On 23 Sep 2007 09:13:59 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
>
> > On 9/23/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > > ># all tests fail with ICE in verify_curr_properties; -m32/-m64
> > > >-O2 -fno-tree-salias
> > > >-Os -fno-tr
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> On 9/23/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > ># all tests fail with ICE in verify_curr_properties; -m32/-m64
> > >-O2 -fno-tree-salias
> > >-Os -fno-tree-salias
> >
> >
> > Known. This is normally the first place we build aliasing info.
On 9/23/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> ># all tests fail with ICE in verify_curr_properties; -m32/-m64
> >-O2 -fno-tree-salias
> >-Os -fno-tree-salias
>
>
> Known. This is normally the first place we build aliasing info.
> Unless we have a compelling reason to have this flag, we sh
># all tests fail with ICE in verify_curr_properties; -m32/-m64
>-O2 -fno-tree-salias
>-Os -fno-tree-salias
Known. This is normally the first place we build aliasing info.
Unless we have a compelling reason to have this flag, we should simply
remove the flag.
> # all tests fail with ICE in ver
On 9/21/07, Janis Johnson <[EMAIL PROTECTED]> wrote:
> # gap, gcc, vortex run fails; -m64
> -fpack-struct
> # eon build fails with (valid?) error; -m32/-m64
> -fpack-struct
These above failures are kinda of expected as -fpack-struct does change the ABI.
Thanks,
Andrew Pinski
In http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01702.html I describe
tools to generate sets of GCC command-line options used to find
combinations that don't work together. Using those tools and a setup
to build and run (with short test input) individual tests from SPEC
CPU2000, I've found the fol
25 matches
Mail list logo