Must-alias analysis
Hi all, how is the must-alias information represented in mainline? Is there something like DEF-USE chains for virtual operands? How can I access this kind of information and where should I look for some examples how to use it? Thank you very much! Regards, Martin
Re: Fwd: conditional assigments vs. "may be used uninitialized"
On Thu, Oct 23, 2008 at 1:55 AM, Xinliang David Li <[EMAIL PROTECTED]> wrote: > > The patch is pretty big, so I am waiting for stage1 is reopened to submit. Posting it when it's ready is a good idea usually to try to get feedback and review while you still remember every line of code. Of course, as usual with GCC, a quick review is not guarateed anyway ... Thanks, Richard. > Thanks, > > David
Re: Must-alias analysis
On Thu, Oct 23, 2008 at 10:46 AM, Martin Schindewolf <[EMAIL PROTECTED]> wrote: > Hi all, > > how is the must-alias information represented in mainline? > Is there something like DEF-USE chains for virtual operands? > How can I access this kind of information and where should I look for some > examples how to use it? > Thank you very much! There is only may-alias information explicitely represented, by virtue of the virtual operands USE-DEF/DEF-USE chains. You have to verify must-alias relation yourself, which is eased by several helper functions, most notable get_ref_base_and_extent () which dissects a memory reference into a base, offset range and access size. You can compare the base for equality using the operand_equal_p function. For pointer bases you can also access points-to information present in the SSA_NAME_PTR_INFO structure. On the alias-improvements branch we hopefully will end up with more specific interfaces to query must-alias information. Richard.
-fno-ira removal
Hi! I think we are now almost a month past the deadline for removal of -fno-ira and ports that haven't been converted to IRA yet. Vladimir, do you plan to move forward with this step any time soon? The following ports haven't been converted yet: arc m32c m68hc11 mmix pdp11 score vax Jakub
Re: -fno-ira removal
> The following ports haven't been converted yet: > > arc m32c m68hc11 mmix pdp11 score vax DJ has reported problems on the list for m32c. Regarding ARC and MMIX we might expect some action from Joern and H-P respectively, but nobody is probably going to do the work for the others Paolo
Re: -fno-ira removal
> > The following ports haven't been converted yet:
> >
> > arc m32c m68hc11 mmix pdp11 score vax
>
> DJ has reported problems on the list for m32c.
>
> Regarding ARC and MMIX we might expect some action from Joern and H-P
> respectively, but nobody is probably going to do the work for the others
>
> Paolo
>
For mingw targets there are also problems about ira. It seems so that the
ira pass doesn't use the mtarget.delegitimize_address hook for mem-refs,
which leads to wrong code for those targets.
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: -fno-ira removal
> Regarding ARC and MMIX we might expect some action from Joern and H-P > respectively, but nobody is probably going to do the work for the others We've faxed the Copyright assignemnt to the FSF on the 3rd of September, with the physical signed copy Fedexed on the 4th and received on the 5th of September. Yet we haven't heared anything from them yet. I've sent a query about the status on the 29th of September to [EMAIL PROTECTED] with CC to [EMAIL PROTECTED], but haven't received any reply then, either. Is there any other contact we should use to find out what is happening?
Re: -fno-ira removal
> The following ports haven't been converted yet: > > m32c I've tried and tried to get IRA for m32c working. I asked Vlad and Jeff to look at it, which they have/are, with no definite results yet.
Re: -fno-ira removal
Jakub Jelinek wrote: Hi! I think we are now almost a month past the deadline for removal of -fno-ira and ports that haven't been converted to IRA yet. Vladimir, do you plan to move forward with this step any time soon? I'd rather wait for 2-3 weeks more. People are still working on some target porting. It is also useful to have the old RA for comparison because there are still IRA performance PRs for some targets. Also I am still working on the patch removing the old RA. I think it will be finally ready on next week. I am sorry for the delay with that. I was quite busy with IRA PRs. The hardest PRs are performance PRs. Their fixes takes most of my time. The following ports haven't been converted yet: arc m32c m68hc11 mmix pdp11 score vax
Use of compute_data_dependences_for_loop on GIMPLE representation
Hello, Can i make use of functions defined in "tree-data-ref.h" for data dependency analysis on GIMPLE trees ? Thanks.
RE: -fno-ira removal
>arc m32c m68hc11 mmix pdp11 score vax I'll try to get to pdp11 soon. paul
Re: -fno-ira removal
On Thu, Oct 23, 2008 at 9:10 AM, Joern Rennecke <[EMAIL PROTECTED]> wrote: >> Regarding ARC and MMIX we might expect some action from Joern and H-P >> respectively, but nobody is probably going to do the work for the others > > We've faxed the Copyright assignemnt to the FSF on the 3rd of September, > with the physical signed copy Fedexed on the 4th and received on the 5th > of September. Yet we haven't heared anything from them yet. > > I've sent a query about the status on the 29th of September to > [EMAIL PROTECTED] with CC to [EMAIL PROTECTED], but haven't received > any reply then, either. > > Is there any other contact we should use to find out what is happening? The FSF is transitioning to a new copyright clerk and have a backlog of assignments to work through. David
Re: -fno-ira removal
On Thu, 23 Oct 2008, Jakub Jelinek wrote: > Hi! > > I think we are now almost a month past the deadline for removal of -fno-ira > and ports that haven't been converted to IRA yet. The plan was to add the ports to the deprecation list (so they can be reenabled by a small patch defining IRA_COVER_CLASSES and removing them from the deprecation list) and remove them after 4.4 branches: only the old allocator would be removed from trunk right now, not the ports themselves. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Use of compute_data_dependences_for_loop on GIMPLE representation
Sure, that's why they are there. On Thu, Oct 23, 2008 at 10:00 AM, <[EMAIL PROTECTED]> wrote: > Hello, > > Can i make use of functions defined in "tree-data-ref.h" for data dependency > analysis on GIMPLE trees ? > > Thanks. > >
scan-assembler harness bug?
In scanasm.exp we do this:
proc scan-assembler { args } {
upvar 2 name testcase
set output_file "[file rootname [file tail $testcase]].s"
However, in dejagnu, $name may have compiler switches appended to it:
# We append the compilation flags, if any, to ensure that the test case
# names are unique.
if { "$tool_flags" != "" } {
set name "$name $tool_flags"
}
Perhaps we want to add this line to scanasm, in various places, to
strip off the compiler switches?
set testcase [lindex $testcase 0]
Re: scan-assembler harness bug?
On Thu, 2008-10-23 at 18:00 -0400, DJ Delorie wrote:
> In scanasm.exp we do this:
>
> proc scan-assembler { args } {
> upvar 2 name testcase
> set output_file "[file rootname [file tail $testcase]].s"
>
>
> However, in dejagnu, $name may have compiler switches appended to it:
>
> # We append the compilation flags, if any, to ensure that the test case
> # names are unique.
> if { "$tool_flags" != "" } {
> set name "$name $tool_flags"
> }
>
> Perhaps we want to add this line to scanasm, in various places, to
> strip off the compiler switches?
>
> set testcase [lindex $testcase 0]
I thought something like that was already done but I couldn't find it
right now. Is it a problem? If so, we should certainly do this.
Janis
gcc-4.3-20081023 is now available
Snapshot gcc-4.3-20081023 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081023/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 141329 You'll find: gcc-4.3-20081023.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20081023.tar.bz2 C front end and core compiler gcc-ada-4.3-20081023.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20081023.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20081023.tar.bz2 C++ front end and runtime gcc-java-4.3-20081023.tar.bz2 Java front end and runtime gcc-objc-4.3-20081023.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20081023.tar.bz2The GCC testsuite Diffs from 4.3-20081016 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: scan-assembler harness bug?
> I thought something like that was already done but I couldn't find it
> right now. Is it a problem? If so, we should certainly do this.
I see it done in other places, but not scanasm. How's this?
2008-10-23 DJ Delorie <[EMAIL PROTECTED]>
* lib/scanasm.exp: Extract first word of $testcase for all upvar
uses.
2008-10-09 Thomas Koenig <[EMAIL PROTECTED]>
Index: lib/scanasm.exp
===
--- lib/scanasm.exp (revision 141026)
+++ lib/scanasm.exp (working copy)
@@ -64,22 +64,24 @@ proc dg-scan { name positive testcase ou
# Look for a pattern in the .s file produced by the compiler. See
# dg-scan for details.
proc scan-assembler { args } {
upvar 2 name testcase
+set testcase [lindex $testcase 0]
set output_file "[file rootname [file tail $testcase]].s"
dg-scan "scan-assembler" 1 $testcase $output_file $args
}
# Check that a pattern is not present in the .s file produced by the
# compiler. See dg-scan for details.
proc scan-assembler-not { args } {
upvar 2 name testcase
+set testcase [lindex $testcase 0]
set output_file "[file rootname [file tail $testcase]].s"
dg-scan "scan-assembler-not" 0 $testcase $output_file $args
}
# Return the scan for the assembly for hidden visibility.
@@ -99,12 +101,13 @@ proc hidden-scan-for { symbol } {
# Check that a symbol is defined as a hidden symbol in the .s file
# produced by the compiler.
proc scan-hidden { args } {
upvar 2 name testcase
+set testcase [lindex $testcase 0]
set output_file "[file rootname [file tail $testcase]].s"
set symbol [lindex $args 0]
set hidden_scan [hidden-scan-for $symbol]
@@ -115,12 +118,13 @@ proc scan-hidden { args } {
# Check that a symbol is not defined as a hidden symbol in the .s file
# produced by the compiler.
proc scan-not-hidden { args } {
upvar 2 name testcase
+set testcase [lindex $testcase 0]
set output_file "[file rootname [file tail $testcase]].s"
set symbol [lindex $args 0]
set hidden_scan [hidden-scan-for $symbol]
set args [lreplace $args 0 0 "$hidden_scan"]
@@ -129,20 +133,22 @@ proc scan-not-hidden { args } {
}
# Look for a pattern in OUTPUT_FILE. See dg-scan for details.
proc scan-file { output_file args } {
upvar 2 name testcase
+set testcase [lindex $testcase 0]
dg-scan "scan-file" 1 $testcase $output_file $args
}
# Check that a pattern is not present in the OUTPUT_FILE. See dg-scan
# for details.
proc scan-file-not { output_file args } {
upvar 2 name testcase
+set testcase [lindex $testcase 0]
dg-scan "scan-file-not" 0 $testcase $output_file $args
}
# Call pass if pattern is present given number of times, otherwise fail.
proc scan-assembler-times { args } {
if { [llength $args] < 2 } {
@@ -163,12 +169,13 @@ proc scan-assembler-times { args } {
}
# This assumes that we are two frames down from dg-test, and that
# it still stores the filename of the testcase in a local variable "name".
# A cleaner solution would require a new dejagnu release.
upvar 2 name testcase
+set testcase [lindex $testcase 0]
# This must match the rule in gcc-dg.exp.
set output_file "[file rootname [file tail $testcase]].s"
set fd [open $output_file r]
set text [read $fd]
@@ -212,12 +219,13 @@ proc scan-assembler-dem { args } {
[findfile $base_dir/c++filt $base_dir/c++filt \
[transform c++filt
verbose -log "c++filt is $cxxfilt"
}
upvar 2 name testcase
+set testcase [lindex $testcase 0]
set output_file "[file rootname [file tail $testcase]].s"
set output [remote_exec host "$cxxfilt" "" "$output_file"]
set text [lindex $output 1]
if [regexp -- [lindex $args 0] $text] {
@@ -257,12 +265,13 @@ proc scan-assembler-dem-not { args } {
[findfile $base_dir/c++filt $base_dir/c++filt \
[transform c++filt
verbose -log "c++filt is $cxxfilt"
}
upvar 2 name testcase
+set testcase [lindex $testcase 0]
set output_file "[file rootname [file tail $testcase]].s"
set output [remote_exec host "$cxxfilt" "" "$output_file"]
set text [lindex $output 1]
if ![regexp -- [lindex $args 0] $text] {
Re: scan-assembler harness bug?
On Thu, 2008-10-23 at 19:12 -0400, DJ Delorie wrote: > > I thought something like that was already done but I couldn't find it > > right now. Is it a problem? If so, we should certainly do this. > > I see it done in other places, but not scanasm. How's this? > > 2008-10-23 DJ Delorie <[EMAIL PROTECTED]> > > * lib/scanasm.exp: Extract first word of $testcase for all upvar > uses. OK, after you've run the testsuite with this change. The ChangeLog entry should show the names of all of the procs you changed. Janis
Re: scan-assembler harness bug?
> OK, after you've run the testsuite with this change. The ChangeLog > entry should show the names of all of the procs you changed. Is gcc.target/i386.exp enough? I originally found it with xstormy16-elf on an older branch, but xstormy16 isn't a happy target in trunk at the moment.
