Re: IRA conflict graph & alternative selection

[Jeff Law]

Ian Lance Taylor wrote:

Jeff Law  writes:

  

Ian Lance Taylor wrote:


Jeff Law  writes:

  
  

No, that makes no sense.  What I'm suggesting is that we fix the stack
offsets of all local variables before register allocation, based on a
conservative assessment of how many registers will be saved on the
stack.  Then we know during register allocation whether the memory
reference will be in or out of the +- 16 byte range.   
  

Just fixing the offset is not sufficient for the case I'm concerned
about because you don't know what offsets are valid until you know
precisely what registers are used in the insn.   That's absolutely
critical.  So you have to assume worst case which is you can only use
the +-16 byte insns which will pessimize just about every stack
reference.



You fix the offset of the value stored on the stack.  Given that, you
know which instruction you can use.
  
  

No, it's not that simple.  If you spill, then you can change the
registers that are used and that in turn changes the set of valid
offsets in reg+d instructions.



We are just talking in circles.  As I have been saying all along, I'm
suggesting that gcc conservatively determine which registers will be
used.  Then spilling will not change the stack space allocated for saved
registers.
  
Conservatively selecting registers for this case would make the 
generated code so bad on this target that GCC would become unusable.  


Most of that loop's real work isn't in the address relaxation code,
but in digging through instructions to determine what needs to be
reloaded and how many registers are necessary to perform the requested
reloads.



You are not using the word "relaxation" in the same sense that I meant
it.  I meant explicitly the process of finding the final set of
elimination offsets.
  
Actually I think I am.  Very little work of the loop is related to 
finding the final set of elimination offsets.  Furthermore, most of the 
time we run through that loop precisely once.   Of the remaining cases 
where the loop iterates more than once, 25% can be trivially eliminated 
through better sequencing of operations in the loop.








Not a conservative guess at pseudo registers, a conservative guess at
hard registers.
  
OK.  I see the difference here, but it doesn't change the problem at 
hand -- a conservative guess at what hard registers we're going to use 
would pessimize the code horribly, possibly more so than making a 
conservative guess about what offsets are going to be valid -- a 
conservative guess on the registers used for these memory operations 
would have a cascading effect throughout the code causing a ton of 
reloading of other instructions.


Jeff

Re: IRA conflict graph & alternative selection

[Jeff Law]

Ian Lance Taylor wrote:

Not a conservative guess at pseudo registers, a conservative guess at
hard registers.

I'm sorry, but I think I'm done with this thread.  I'm just repeating
myself, and people are critiquing things which I am not saying.
  
FWIW, I'm not trying to be dense -- I respect and value your opinions.  
We're clearly not communicating well.


jeff

RE: libiberty testsuite builds with wrong compiler

[Jack Howarth]

  The same issue in the libiberty testsuite run can be seen with
the Apple regress server log at 
http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip.
If you search for test-demangle, you will find...

+ make -j2 -k check
autogen -T /Users/regress/tbox/svn-gcc/fixincludes/check.tpl 
/Users/regress/tbox/svn-gcc/fixincludes/inclhack.def
make[2]: autogen: Command not found
make[2]: *** [check] Error 127
make[1]: *** [check-fixincludes] Error 2
rm -f stamp-h1
/bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
Makefile:3354: warning: overriding commands for target `gt-darwin.h'
/Users/regress/tbox/svn-gcc/gcc/config/t-darwin:17: warning: ignoring old 
commands for target `gt-darwin.h'
make[2]: Nothing to be done for `check'.
Making a new config file...
make[2]: Nothing to be done for `check'.
echo "set tmpdir /Users/regress/tbox/native/build/gcc/testsuite" >> ./tmp0
gcc -DHAVE_CONFIG_H -g -O2 -I.. 
-I/Users/regress/tbox/svn-gcc/libiberty/testsuite/../../include  -o 
test-demangle \
/Users/regress/tbox/svn-gcc/libiberty/testsuite/test-demangle.c 
../libiberty.a
Makefile:3354: warning: overriding commands for target `gt-darwin.h'

and

if [ -n "" ] ; then \
  runtestflags=""; \
elif [ -n "execute.exp=execute/2* execute.exp=execute/\[013-9a-zA-Z\]* 
compile.exp dg.exp struct-layout-1.exp,unsorted.exp,stackalign.exp,i386.exp" ] 
; then \
  parts="`echo ' execute.exp=execute/2* execute.exp=execute/\[013-9a-zA-Z\]* 
compile.exp dg.exp struct-layout-1.exp unsorted.exp stackalign.exp i386.exp ' \
  | sed 's/=[^ ]* / /g'`"; \
  for part in `find $srcdir/testsuite/gcc* -name \*.exp` ; do \
part=`basename $part` ; \
case " $parts $runtestflags " in \
  *" $part "*) ;; \
  *) runtestflags="$runtestflags $part" ;; \
esac ; \
  done ; \
fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo 
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc  $runtestflags)
gcc -DHAVE_CONFIG_H -g -O2 -I.. 
-I/Users/regress/tbox/svn-gcc/libiberty/testsuite/../../include  
-DHAVE_CONFIG_H -I.. -o test-pexecute \
/Users/regress/tbox/svn-gcc/libiberty/testsuite/test-pexecute.c 
../libiberty.a
gcc -DHAVE_CONFIG_H -g -O2 -I.. 
-I/Users/regress/tbox/svn-gcc/libiberty/testsuite/../../include  
-DHAVE_CONFIG_H -I.. -o test-expandargv \
/Users/regress/tbox/svn-gcc/libiberty/testsuite/test-expandargv.c 
../libiberty.a
./test-demangle < 
/Users/regress/tbox/svn-gcc/libiberty/testsuite/demangle-expected
./test-demangle: 775 tests, 0 failures

etc. All of which are using the system c compiler instead of that from gcc 
trunk.
   Jack

libiberty testsuite builds with wrong compiler

[Jack Howarth]

I noticed the following on darwin10, since it builds
with x86_64 as the default where appropriate. The 
libiberty testsuite is building with the system compiler
instead of the one from gcc trunk...

make[2]: [check-objc] Error 1 (ignored)
make[2]: Nothing to be done for `check'.
make[2]: Nothing to be done for `check'.
make[2]: Nothing to be done for `check'.
gcc -DHAVE_CONFIG_H -g -O2 -I.. 
-I../../../gcc-4.4-20090221/libiberty/testsuite/../../include  -o test-demangle 
\
../../../gcc-4.4-20090221/libiberty/testsuite/test-demangle.c 
../libiberty.a

This was flagged on darwin10 because libiberty.a is built
with the gcc trunk compiler and is i386 code not x86_64 code.
  Jack

Re: IRA conflict graph & alternative selection

[Ian Lance Taylor]

Jeff Law  writes:

> Ian Lance Taylor wrote:
>> Jeff Law  writes:
>>
>>   
 No, that makes no sense.  What I'm suggesting is that we fix the stack
 offsets of all local variables before register allocation, based on a
 conservative assessment of how many registers will be saved on the
 stack.  Then we know during register allocation whether the memory
 reference will be in or out of the +- 16 byte range.   
>>> Just fixing the offset is not sufficient for the case I'm concerned
>>> about because you don't know what offsets are valid until you know
>>> precisely what registers are used in the insn.   That's absolutely
>>> critical.  So you have to assume worst case which is you can only use
>>> the +-16 byte insns which will pessimize just about every stack
>>> reference.
>>> 
>>
>> You fix the offset of the value stored on the stack.  Given that, you
>> know which instruction you can use.
>>   
> No, it's not that simple.  If you spill, then you can change the
> registers that are used and that in turn changes the set of valid
> offsets in reg+d instructions.

We are just talking in circles.  As I have been saying all along, I'm
suggesting that gcc conservatively determine which registers will be
used.  Then spilling will not change the stack space allocated for saved
registers.


>>> Perhaps the confusion in this case is because we're not really
>>> relaxing -- we're dealing with a case where the offset alone isn't
>>> enough to determine if the addressing mode is valid.
>>> 
>>
>> The confusion may be that we may be talking about different things.
>> I'm talking about removing this loop in the reload function:
>>
>>   /* This loop scans the entire function each go-round
>>  and repeats until one repetition spills no additional hard regs.  */
>>   
> Most of that loop's real work isn't in the address relaxation code,
> but in digging through instructions to determine what needs to be
> reloaded and how many registers are necessary to perform the requested
> reloads.

You are not using the word "relaxation" in the same sense that I meant
it.  I meant explicitly the process of finding the final set of
elimination offsets.


>> You know the size of the frame, by guessing conservatively as to how
>> many registers will be required.
>>   
> A conservative guess would be something like "every pseudo needs a
> slot" -- anything less than that isn't conservative, it's  optimistic.

Not a conservative guess at pseudo registers, a conservative guess at
hard registers.

I'm sorry, but I think I'm done with this thread.  I'm just repeating
myself, and people are critiquing things which I am not saying.

Ian

virtual destructors and operator delete

[Piotr Wyderski]

Hi,

I have an auto-duration only class X in C++0x:

class X {

void* operator new(std::size_t) = delete;
void operator delete(void*) = delete;

public:

virtual ~X() {}
};

But GCC 4.4 fails to compile it:

main.cpp: In destructor 'virtual X::~X()':
main.cpp:4140: error: deleted function 'static void X::operator delete(void*)'
main.cpp:4144: error: used here

Is it a bug? If not, then why is it needed?
I have a similar example with a missing "unneeded" copy constructor.

Best regards, Piotr

Re: Stop daily bumps on autovect-branch?

[Richard Guenther]

On Sat, Feb 21, 2009 at 1:30 PM, Joseph S. Myers
 wrote:
> On Sat, 21 Feb 2009, Steven Bosscher wrote:
>
>> Hi,
>>
>> No changes were checked in on the autovect-branch in the last ~15
>> months, but the branch still gets a daily bump on DATESTAMP.
>
> When I moved a lot of branches to the list of inactive branches in
> svn.html last July
>  I didn't move
> autovect-branch because it had seen at least one commit (other than the
> DATESTAMP updates) within the previous year.  This fits with your
> observation of no changes in 15 months, and by my definition it would
> indeed now be an inactive branch.

Apart from that, we shouldn't do DATESTAMP updates on random branches.

Richard.

Re: Stop daily bumps on autovect-branch?

[Joseph S. Myers]

On Sat, 21 Feb 2009, Steven Bosscher wrote:

> Hi,
> 
> No changes were checked in on the autovect-branch in the last ~15
> months, but the branch still gets a daily bump on DATESTAMP.

When I moved a lot of branches to the list of inactive branches in 
svn.html last July 
 I didn't move 
autovect-branch because it had seen at least one commit (other than the 
DATESTAMP updates) within the previous year.  This fits with your 
observation of no changes in 15 months, and by my definition it would 
indeed now be an inactive branch.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Stop daily bumps on autovect-branch?

[Gerald Pfeifer]

On Sat, 21 Feb 2009, Richard Guenther wrote:
> Huh, we do that?  Yeah, feel free to adjust
> maintainer_scripts/update_version_svn.

I'm not sure Steven is on the gccadmin account, so I went ahead and
committed the change below and also updated the script that is run
by the crontab on gcc.gnu.org itself.

Gerald

2009-02-21  Gerald Pfeifer  

* update_version_svn (ADD_BRANCHES): Remove autovect-branch
and document format.

Index: update_version_svn
===
--- update_version_svn  (revision 144334)
+++ update_version_svn  (working copy)
@@ -3,11 +3,11 @@
 # Update the current version date in all files in the tree containing
 # it.  Consider all release branches except those matching the regular
 # expression in $IGNORE_BRANCHES, and also consider those branches listed
-# in $ADD_BRANCHES.
+# in the space separated list in $ADD_BRANCHES.
 
 SVNROOT=${SVNROOT:-"file:///svn/gcc"}
 IGNORE_BRANCHES='gcc-(2_95|3_0|3_1|3_2|3_3|3_4|4_0|4_1)-branch'
-ADD_BRANCHES='HEAD autovect-branch'
+ADD_BRANCHES='HEAD'
 
 # Run this from /tmp.
 export SVNROOT

Re: Stop daily bumps on autovect-branch?

[Richard Guenther]

On Sat, Feb 21, 2009 at 11:20 AM, Steven Bosscher  wrote:
> Hi,
>
> No changes were checked in on the autovect-branch in the last ~15
> months, but the branch still gets a daily bump on DATESTAMP.
>
> Perhaps time to stop doing that?

Huh, we do that?  Yeah, feel free to adjust
maintainer_scripts/update_version_svn.

Thanks,
Richard.

> Gr.
> Steven
>

Stop daily bumps on autovect-branch?

[Steven Bosscher]

Hi,

No changes were checked in on the autovect-branch in the last ~15
months, but the branch still gets a daily bump on DATESTAMP.

Perhaps time to stop doing that?

Gr.
Steven

Re: targed.md: copy_to_mode_reg or force_reg?

[Joern Rennecke]

in machine description expanders the functions copy_to_mode_reg
and and force_reg from explow.c can be used to ensure that an operand
lives in a register.

But what function should be used?

What are the differences? The only difference I can depict from the comment
is that an operand returned by force_reg must not be altered, i.e.
overwritten afterwards.


If you just want an operand in a register and want to avoid unnecessary
register-register copies, use force_reg.  Note that if the operand was already
in a regsiter, you will retain that register, which may not only be live
after the expanded code, it could also (alterantively or additionally)
be in a hard register or a virtual register, which, depending on the
exact requirements of your instruction pattern. can cause issues
when virtual registers are instantiated or when it comes to register  
allocation.


If you want to make sure that you get a pseudo register that you are free to
modify as you whish, use copy_to_mode_reg.

If you want to make your own decision if the value / register should  
be copied,

guard a copy_to_mode_reg call with your own condition.


Are there any pitfalls using these functions with respect to
reload_completed, reload_in_progress or no_new_pseudos?


Yes and no.  You should never, ever do that during / after reload.  But that
is not considered a pitfall, but obvious.


By the way: Are there better places to ask such questions like in gcc-help?


If you actually need a new gcc backend and want it to be done well. you
should instruct an experienced contractor to do it for you, or hire an
in-house expert.

Your question reveals that you are not familiar with gcc, and further
suggests that you are trying to implement a new backend alone or in a team
lacking a gcc expert.  This is likely to either fail or result in a
backend of substandard quality which will never make it into the FSF
repository.
You might eventually (after several years) improve and come up with a
proper backend, but you will likely pick up the necessary skills more
quickly if you start out with something less ambitious, like improving
an existing backend, and have your patches peer-reviewed on the gcc
mailing list.
Or if you directly cooperate in implementing your new backend with someone
who already has the necessary experience.

Thus, although your orginal question is valid in principle on this list,
answering is not likely to really help you, nor are you likely to help
the GCC community in the forseeable future if you are working on an
over-ambitious project project.
Thus, there is little incentive for anybody knowledgable reading this
list to answer this question.

If the same question had been asked in a different context, e.g. a small
patch to the x86 backend in order to support some new and exciting linux
application, the odds of getting a timely response would have been higher.


It's hard to believe that all the existing gcc backends are written by
copy & past and trial & error, rather than by understand & implement.


If you know what you are doing - i.e. you already understand the subject
matter - copy & past & adjust can be a useful tool:
If you know that the backend you are implmeneting shares certain aspects with
an existing target, you can copy & paste the code that deals with these
aspects and adjust to fit.

And of course a lot of code is written from scratch according to spec.  Its
just that documentation and comments tend to focus on things that people
think merit documenting.  force_reg and copy_to_mode_reg are rather simple
functions, so just glancing at the source tells you what they do.
Of course, if you have a copyright assignment on file, you can submit a patch
to improve the documentation in places where you think it is lacking.

Concerning the GCC internals: What place is the best to get the most  
up to date version of it? The online version has several  
inconsistencies, so it is very hard to understand and remove  
sophisticated backend problems and defiecencies.


You can also read the doc/*.texi files from the subversion repository.

If you find an inconsistency in the documentation, please post the issue
to the list.