[txcorp.com #18026] Resolved: 3ware 3DM2 alert -- host: octet.carys.home

[Tech-X Internal IT Support via RT]

According to our records, your request has been resolved. If you have any
further questions or concerns, please reply to this email.

Account for devirtualization opportunities in inlining heuristics

[Maxim Kuvyrkov]

Jan,

Here are the testcases for inlining improvements we've discussed on IRC a 
couple of days ago.

Current mainline handles inline-devirt-1.C and inline-devirt-5.C cases.  With 
my w-i-p patches to teach inlining heuristics about devirtualization 
opportunities (also attached) inline-devirt-2.C, inline-devirt-3.C are also 
fully optimized.

Let me know if you have suggestions for tackling the other cases.

Do you think committing the testcases mainline, XFAIL'ed as necessary, would be 
useful?

Thanks,

--
Maxim Kuvyrkov
CodeSourcery
+1-650-331-3385 x724



0005-Testcases.patch
Description: Binary data


0002-Refactor-ipa-cp.c-to-operate-on-type-lattices.ChangeLog
Description: Binary data


0002-Refactor-ipa-cp.c-to-operate-on-type-lattices.patch
Description: Binary data


0003-Fix-memory-leak.ChangeLog
Description: Binary data


0003-Fix-memory-leak.patch
Description: Binary data


0004-Account-for-devirtualization-in-inlining-heuristics.ChangeLog
Description: Binary data


0004-Account-for-devirtualization-in-inlining-heuristics.patch
Description: Binary data

Re: register allocation

[roy rosen]

2010/12/23 Vladimir Makarov :
> On 12/23/2010 03:13 AM, roy rosen wrote:
>>
>> Hi All,
>>
>> I am looking at the code generated by my port and it seems that I have
>> a problem that too many copies between registers are generated.
>> I looked a bit at the register allocation and wanted to verify that I
>> understand its behavior.
>>
>> Is that true that it first chooses a register class for each pseodo
>> and only then starts coloring?
>>
> Yes, that is true.
>>
>> I think that my problem is that in my architecture there are two
>> register classes which can do all arithmetic operation but class X can
>> also do loads and stores and class Y can also do DSP operations.
>>
>> So when there are for example two DSP operations and between them some
>> arithmetic operations I expect to use only class Y but GCC prefers to
>> copy registers and do the arithmetic operations using X because for
>> some reason it determined that the prefered class for the registers in
>> the arithmetic operations is X.
>>
>> It seems that determining the class does not look at the whole flow
>> but rather looks only at insns in which the register appears.
>>
> Defining classes for pseudos is already one of the most expensive operation
> in IRA.  Looking at the flow would make it even more complicated (I even
> don't know how to use this to improve the allocation because it means live
> range splitting before coloring and before defining classes which could help
> do live range splitting reasonably taking register pressure into account).
>>
>> Do I understand the situation correctly?
>
> Yes, I guess.
>>
>> Is there something I can do about it?
>
> I'd recommend to try ira-improv branch.  I think that part of the problem is
> in usage of cover classes.  The branch removes the cover classes and permits
> IRA to use intersected register classes and that helps to assign better hard
> registers.
>
>

I tried now this branch and got better results for some cases but
still in other cases I get lots of redundent register copies.
I might be missing something from the gcc history but I wonder why do
we need to limit the coloring stage to select a hard reg from a class
that was chosen by a prior stage.
Why not simply put in the interference graph edges for all registers
which are not possible for a pseudo and let the coloring algorithm
select the best hard reg.
It seems that choosing a class for a pseudo before the coloring only
makes it impossible for the coloring to get to the best solution.

Roy.

Problem updating 2yr old port

[Christian Grössler]

Hello,

I'm trying to make a port to a new architecture work on the current gcc. There 
hasn't been any work
done on this port since Nov-2008.

The compiler builds now, but I'm getting an ICE when I try to compile a program.

-
X:
--
(mem/f/c/i:PSI (plus:PSI (reg/f:PSI 87 virtual-stack-vars)
(const_int -12 [0xfff4])) [0 str+0 S4 A32])
Y:
--
(const_int 0 [0])
--

In file included from /cool/tmp/argz_add.c:7:0:
/cool/merge/cool-gcc/src/newlib/libc/include/argz.h: In function 'argz_add':
/cool/merge/cool-gcc/src/newlib/libc/include/argz.h:23:9: internal compiler 
error: in prepare_cmp_insn, at optabs.c:4159
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
--

These "X" and "Y" messages are debug messages which I've added with 
print_inline_rtx().

The offending line in the source file is

  if (str == NULL)
return 0;

str is a "const char *". Pointers are using PSI mode on this architecture, 
since they are only 20 bits wide.

The inputs x and y to prepare_cmp_insn are in PSImode and VOIDmode, and it seems
the compiler cannot compare these modes anymore.

The old version of prepare_cmp_insn() called can_compare_p() at this point 
which returned success and all was well.
Now can_compare_p() is only called for MODE_CC modes.

Looking at the history of optabs.c, the MODE_CC test was introduced when 
merging the cond-optab branch
to main. I didn't find a description of the cond-optab branch and what it was 
supposed to do.

Can anybody give me some hints how to continue from here? I'm rather new to gcc 
hacking and don't have
yet the big picture of a gcc backend. Not even the details. :-)

regards,
chris

Re: Problem updating 2yr old port

[Ian Lance Taylor]

Christian Grössler  writes:

> Looking at the history of optabs.c, the MODE_CC test was introduced when 
> merging the cond-optab branch
> to main. I didn't find a description of the cond-optab branch and what it was 
> supposed to do.

This is the description of the now-merged cond-optab branch, from
http://gcc.gnu.org/ml/gcc/2009-04/msg00211.html :

This branch is to clean up and simplify the implementation of
conditional operations (branches, stores, moves, etc.) in expand and
in the machine descriptions.  Patches should be marked with the tag
[cond-optab] in the subject line.  The branch is maintained by Paolo
Bonzini.  Pending further testing, the branch is ready to be merged
into mainline and only bug and documentation fixes should be
committed.

As I recall the basic idea was to generate all conditional branches via
the cbranchMODE4 pattern rather than using separate compare and branch
patterns.

I couldn't figure out which assertion you hit so I'm not sure what else
to say.  A const_int is always VOIDmode, and there should be no problem
comparing a value to a const_int.

Ian

Re: Problem updating 2yr old port

[Christian Grössler]

On 28.12.10 00:22, Ian Lance Taylor wrote:

Christian Grössler  writes:


Looking at the history of optabs.c, the MODE_CC test was introduced when 
merging the cond-optab branch
to main. I didn't find a description of the cond-optab branch and what it was 
supposed to do.


This is the description of the now-merged cond-optab branch, from
http://gcc.gnu.org/ml/gcc/2009-04/msg00211.html :

 This branch is to clean up and simplify the implementation of
 conditional operations (branches, stores, moves, etc.) in expand and
 in the machine descriptions.  Patches should be marked with the tag
 [cond-optab] in the subject line.  The branch is maintained by Paolo
 Bonzini.  Pending further testing, the branch is ready to be merged
 into mainline and only bug and documentation fixes should be
 committed.

As I recall the basic idea was to generate all conditional branches via
the cbranchMODE4 pattern rather than using separate compare and branch
patterns.


Yeah, so I seem to need to add a cbranchMODE4 pattern. I tried it, but it 
didn't help.
Probably because I'm not fit enough yet to write a proper pattern (I copied one 
from
ia64 and modified it to see if it gets picked up, but it didn't happen).



I couldn't figure out which assertion you hit so I'm not sure what else
to say.  A const_int is always VOIDmode, and there should be no problem
comparing a value to a const_int.


Sorry, the line numbers in the ICE are wrong, since I added some debug messages.
The abort happens here in prepare_cmp_insn():

  /* Handle a libcall just for the mode we are using.  */
  libfunc = optab_libfunc (cmp_optab, mode);
  gcc_assert (libfunc);<-- HERE


regards,
chris

Re: Problem updating 2yr old port

[Ian Lance Taylor]

Christian Grössler  writes:

> Sorry, the line numbers in the ICE are wrong, since I added some debug 
> messages.
> The abort happens here in prepare_cmp_insn():
>
>   /* Handle a libcall just for the mode we are using.  */
>   libfunc = optab_libfunc (cmp_optab, mode);
>   gcc_assert (libfunc);<-- HERE

Seems like you don't have a cbranchMODE4 insn in the required mode.
Double check that.  You should only get to that assert if there is no
cbranch pattern.  To assert is indicating that if there is no cbranch
pattern there has to be a cmp pattern.  gcc doesn't have any other
options for a compare-and-branch.

Ian