Re: GCC ssa and alias info

[Diego Novillo]

2008/2/12 Dasarath Weeratunge <[EMAIL PROTECTED] 
>:


> Is it possible to dump the ssa representation and alias information
> generated by the compiler to a file?

Yes. If you are using 4.3+, alias analysis is a TODO item, so it's run 
if a pass requests it. If you use -fdump-tree-salias-vops, you'll get 
the very first dump of alias analysis (after the creation of structure 
vars). Otherwise, just use -fdump-tree-all-vops. You can grep which 
passes requested alias analysis by grepping for 'points-to' in the dumps.


If you are using pre 4.3, then -fdump-tree-alias-vops will work.


Diego.

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

[Hans-Peter Nilsson]

> Date: Tue, 12 Feb 2008 13:29:39 -0500
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>

> On Tue, Feb 12, 2008 at 07:20:52PM +0100, Hans-Peter Nilsson wrote:
> > > Date: Tue, 12 Feb 2008 13:16:27 -0500
> > > From: Daniel Jacobowitz <[EMAIL PROTECTED]>
> > 
> > > Just for completeness: -rpath is
> > > only used at runtime, it doesn't even have to be a Unix path.
> > 
> > Incorrect; -rpath is used at both link and runtime.
> 
> Yes, I was slightly mistaken.  The manual says "Searching -rpath in
> this way is only supported by native linkers and cross linkers which
> have been configured with the --with-sysroot option."

The "this way" is ambiguous.  What exactly does it refer to?
I can't tell!

I didn't configure with --with-sysroot, and the -rpath entry
mentions (truthfully) that it is followed for both link and
runtime, no exceptions or special cases.

brgds, H-P
PS. Follow-up-to [EMAIL PROTECTED]

Re: GCC ssa and alias info

[Rogelio M. Serrano Jr.]

Manuel López-Ibáñez wrote:

Check options -fdump-tree-* in the GCC documentation.

Cheers,

Manuel.

  

Can this dump then be used to generate a running excutable?


On 12/02/2008, Dasarath Weeratunge <[EMAIL PROTECTED]> wrote:
  

Is it possible to dump the ssa representation and alias information
generated by the compiler to a file?

thanks,
-- dasarath




  



--
QuarQ Systems and Consulting
   Technological Independence with Open Source




signature.asc
Description: OpenPGP digital signature

Re: GCC ssa and alias info

[Diego Novillo]

On Tue, Feb 12, 2008 at 8:26 PM, Rogelio M. Serrano Jr.
<[EMAIL PROTECTED]> wrote:

>  Can this dump then be used to generate a running excutable?

No.  The output is not valid C, but a pretty printed version of GCC's
internal representation.


Diego.

Re: ICE in delete_output_reload

[Michael Eager]

Ian Lance Taylor wrote:

Michael Eager <[EMAIL PROTECTED]> writes:


I patched the code to only count the occurrence if the
locations are different.  Any idea if that has adverse
consequences?


I would expect that to work.  But before bringing it back to mainline
I'd like to find out why the locations are the same.


The failing source is simple:
width = -width;

The RTL is more or less (I don't have it in front of me)
  (set (reg 140) (neg (reg 140)))

It looks like both (reg 140) are translated into a stack
reference (mem).  Reload attempts to delete one of
the output reloads, and the assert fails.

This only happens in a large compile, so it appears to be
the result of register pressure.  If I cut out some code,
the ICE disappears.


In case it helps, this is where reg_equiv_alt_mem came in:
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01136.html
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00070.html

Thanks.  I think I saw one or perhaps both.  I'll look again.

Has anyone ever done a description of reg allocation or reload?


Just http://gcc.gnu.org/wiki/reload , I think.


Thanks.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

ICE in delete_output_reload

[Michael Eager]

I'm trying to understand an assertion failure in reload1.c:8135.

In delete_output_reload(), I'm getting an assertion failure
in this code:

  for (i1 = reg_equiv_alt_mem_list [REGNO (reg)]; i1; i1 = XEXP (i1, 1))
{
  gcc_assert (!rtx_equal_p (XEXP (i1, 0), substed));
  n_occurrences += count_occurrences (PATTERN (insn), XEXP (i1, 0), 0);
}

Sure enough, i1 matches substed.

reg_equiv_memory_loc[regno] (the source for substed) is the same as 
reg_equiv_alt_mem_list[regno].


Why is this unexpected and what might cause it?

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

[Hans-Peter Nilsson]

> From: Ian Lance Taylor <[EMAIL PROTECTED]>
> Date: 12 Feb 2008 07:48:51 -0800

Thanks to all.  I no longer think there's anything that needs
fixing in the gcc testsuite regarding copying of libraries or in
particular libgcc_s.so.1; I just need my baseboard-file to copy
over every *.so* from ld_library_path or make them otherwise
accessible.  It seems dejagnu deliberately leaves this to the
target, as it's not done for any other library either, and
ld_library_path is the blessed variable (no, not in the dejagnu
*documentation*; just used in the dejagnu sources with the same
use as in gcc. ;)

> Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:
> 
> > Apparently tricks are needed as the -rpath is used both at
> > run-time and at link-time, ld complains about "No such file or
> > directory" if the path doesn't exist on the host side.
> 
> -rpath-link is your friend here.

You mean a -rpath followed by -rpath-link (the latter overriding
for the link)?  That might do it.

> In the past I've just manually copied the libraries over to the target
> board, though.  I've used an NFS mount too, but since the target board
> is usually slow adding additional NFS lookups to every test is just
> more pain.

That might be interpreted as "NFS setups are slower" so to
disambiguate: people have reported NFS setups being
significantly faster (than copy-based protocols).  There's
reason: you wouldn't have to copy the whole program over for
each test, instead letting Linux page it in.  Copying just the
*libraries* would probably help of course.

brgds, H-P

Re: GCC ssa and alias info

[Manuel López-Ibáñez]

Check options -fdump-tree-* in the GCC documentation.

Cheers,

Manuel.

On 12/02/2008, Dasarath Weeratunge <[EMAIL PROTECTED]> wrote:
> Is it possible to dump the ssa representation and alias information
> generated by the compiler to a file?
>
> thanks,
> -- dasarath
>

Re: LLVM 2.2

[Duncan Sands]

> One of the big changes is that we now recommend the GCC 4.2-based  
> front-end,

Another is that it supports Ada (32 bit x86 on linux only for the moment)
and Fortran to some extent.  I'm currently adding build instructions for
these two languages to http://llvm.org/docs/CFEBuildInstrs.html (should
be up in a day or two).  The release notes detail what works and what
doesn't.

Ciao,

Duncan.

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

[Daniel Jacobowitz]

On Tue, Feb 12, 2008 at 07:20:52PM +0100, Hans-Peter Nilsson wrote:
> > Date: Tue, 12 Feb 2008 13:16:27 -0500
> > From: Daniel Jacobowitz <[EMAIL PROTECTED]>
> 
> > On Tue, Feb 12, 2008 at 05:13:45AM +0100, Hans-Peter Nilsson wrote:
> > > Thanks to you and David Daney.  Have you used it yourself?
> > > Apparently tricks are needed as the -rpath is used both at
> > > run-time and at link-time, ld complains about "No such file or
> > > directory" if the path doesn't exist on the host side.
> > 
> > Ian already mentioned -rpath-link.  Just for completeness: -rpath is
> > only used at runtime, it doesn't even have to be a Unix path.
> 
> Incorrect; -rpath is used at both link and runtime.

Yes, I was slightly mistaken.  The manual says "Searching -rpath in
this way is only supported by native linkers and cross linkers which
have been configured with the --with-sysroot option."

I don't remember why that exception is there.

-- 
Daniel Jacobowitz
CodeSourcery

Re: ICE in delete_output_reload

[Ian Lance Taylor]

Michael Eager <[EMAIL PROTECTED]> writes:

> I'm trying to understand an assertion failure in reload1.c:8135.
> 
> In delete_output_reload(), I'm getting an assertion failure
> in this code:
> 
>for (i1 = reg_equiv_alt_mem_list [REGNO (reg)]; i1; i1 = XEXP (i1, 1))
>  {
>gcc_assert (!rtx_equal_p (XEXP (i1, 0), substed));
>n_occurrences += count_occurrences (PATTERN (insn), XEXP (i1, 0), 0);
>  }
> 
> Sure enough, i1 matches substed.
> 
> reg_equiv_memory_loc[regno] (the source for substed) is the same as
> reg_equiv_alt_mem_list[regno].
> 
> Why is this unexpected and what might cause it?

It's unexpected because you shouldn't see the same memory location in
reg_equiv_memory_loc and req_equiv_alt_mem_list.  The memory location
which holds the value should not also be an alternate location for the
value.

The check is there because if they are equal for some reason we will
miscount occurrences.  We already counted occurrences in SUBSTED.

I realize that this is probably not very helpful.

In case it helps, this is where reg_equiv_alt_mem came in:

http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01136.html
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00070.html

Ian

LLVM 2.2

[Chris Lattner]

Hi all,

For anyone who is interested, we just released LLVM 2.2 with numerous  
enhancements:

http://lists.cs.uiuc.edu/pipermail/llvm-announce/2008-February/25.html
http://llvm.org/releases/2.2/docs/ReleaseNotes.html#whatsnew

One of the big changes is that we now recommend the GCC 4.2-based  
front-end,


-Chris

Re: ICE in delete_output_reload

[Michael Eager]

Ian Lance Taylor wrote:

Michael Eager <[EMAIL PROTECTED]> writes:


I'm trying to understand an assertion failure in reload1.c:8135.

In delete_output_reload(), I'm getting an assertion failure
in this code:

   for (i1 = reg_equiv_alt_mem_list [REGNO (reg)]; i1; i1 = XEXP (i1, 1))
 {
   gcc_assert (!rtx_equal_p (XEXP (i1, 0), substed));
   n_occurrences += count_occurrences (PATTERN (insn), XEXP (i1, 0), 0);
 }

Sure enough, i1 matches substed.

reg_equiv_memory_loc[regno] (the source for substed) is the same as
reg_equiv_alt_mem_list[regno].

Why is this unexpected and what might cause it?


It's unexpected because you shouldn't see the same memory location in
reg_equiv_memory_loc and req_equiv_alt_mem_list.  The memory location
which holds the value should not also be an alternate location for the
value.

The check is there because if they are equal for some reason we will
miscount occurrences.  We already counted occurrences in SUBSTED.

I realize that this is probably not very helpful.


:-)

I patched the code to only count the occurrence if the
locations are different.  Any idea if that has adverse
consequences?


In case it helps, this is where reg_equiv_alt_mem came in:

http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01136.html
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00070.html


Thanks.  I think I saw one or perhaps both.  I'll look again.

Has anyone ever done a description of reg allocation or reload?

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

[Hans-Peter Nilsson]

> Date: Tue, 12 Feb 2008 13:16:27 -0500
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>

> On Tue, Feb 12, 2008 at 05:13:45AM +0100, Hans-Peter Nilsson wrote:
> > Thanks to you and David Daney.  Have you used it yourself?
> > Apparently tricks are needed as the -rpath is used both at
> > run-time and at link-time, ld complains about "No such file or
> > directory" if the path doesn't exist on the host side.
> 
> Ian already mentioned -rpath-link.  Just for completeness: -rpath is
> only used at runtime, it doesn't even have to be a Unix path.

Incorrect; -rpath is used at both link and runtime.

brgds, H-P

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

[Daniel Jacobowitz]

On Tue, Feb 12, 2008 at 05:13:45AM +0100, Hans-Peter Nilsson wrote:
> Thanks to you and David Daney.  Have you used it yourself?
> Apparently tricks are needed as the -rpath is used both at
> run-time and at link-time, ld complains about "No such file or
> directory" if the path doesn't exist on the host side.

Ian already mentioned -rpath-link.  Just for completeness: -rpath is
only used at runtime, it doesn't even have to be a Unix path.  But
the linker may need something else in order to find the libraries
at link time, -L or -rpath-link or both.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

[Ian Lance Taylor]

Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:

> Apparently tricks are needed as the -rpath is used both at
> run-time and at link-time, ld complains about "No such file or
> directory" if the path doesn't exist on the host side.

-rpath-link is your friend here.

In the past I've just manually copied the libraries over to the target
board, though.  I've used an NFS mount too, but since the target board
is usually slow adding additional NFS lookups to every test is just
more pain.

Ian

This company is being noticed

[samifawy75493]

We first brought PERT to you back in OCT when it was at only .03

This stock is at a low, and the best buy in stage ever!  With US Navy testing 
going great, prices have dropped in anticipation of news.

With the news of the US Navy's intrest. Many others are taking notice and 
making inquires to this company.

We know this solid nuts and bolts company has something big brewing and will 
rebound strong.  

This opportunity doesn't come along every day. It's knocking now, will you 
answer?  

Next week don't find yourself saying "I wish I bought it last week at .42".

Buy pert first thing Tuesday and watch it climb back up to a dollar next week.

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

[Ian Lance Taylor]

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> Yes, I was slightly mistaken.  The manual says "Searching -rpath in
> this way is only supported by native linkers and cross linkers which
> have been configured with the --with-sysroot option."
> 
> I don't remember why that exception is there.

Because in those cases it is reasonable to assume that the executable
will run in the same environment in which it is being linked (with
sysroot the -rpath refers to directories within the sysroot, at least
I hope it does).  So basically in those cases -rpath is taken to imply
-rpath-link.  But -rpath-link will still be searched first.

Ian

GCC ssa and alias info

[Dasarath Weeratunge]

Is it possible to dump the ssa representation and alias information
generated by the compiler to a file?

thanks,
-- dasarath

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

[Nathan Froyd]

On Tue, Feb 12, 2008 at 05:13:45AM +0100, Hans-Peter Nilsson wrote:
> > From: Nathan Froyd <[EMAIL PROTECTED]>
> > One way to do it is with NFS mounts and setting -Wl,-dynamic-linker
> > -Wl,-rpath for your ldflags.
> 
> Thanks to you and David Daney.  Have you used it yourself?
> Apparently tricks are needed as the -rpath is used both at
> run-time and at link-time, ld complains about "No such file or
> directory" if the path doesn't exist on the host side.

I do use it, but I forgot to mention one other piece of the setup I use:
identical paths on the host and the target.  e.g.:

host:/path/to/gcc   gets mounted at
target:/mount/path/to/gcc   gets symlinked to
target:/path/to/gcc

-Nathan

Re: ICE in delete_output_reload

[Ian Lance Taylor]

Michael Eager <[EMAIL PROTECTED]> writes:

> I patched the code to only count the occurrence if the
> locations are different.  Any idea if that has adverse
> consequences?

I would expect that to work.  But before bringing it back to mainline
I'd like to find out why the locations are the same.

> > In case it helps, this is where reg_equiv_alt_mem came in:
> > http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01136.html
> > http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00070.html
> 
> Thanks.  I think I saw one or perhaps both.  I'll look again.
> 
> Has anyone ever done a description of reg allocation or reload?

Just http://gcc.gnu.org/wiki/reload , I think.

Ian