Re: Switching to C++ by default in 4.8

[Robert Dewar]

On 4/16/2012 5:36 AM, Chiheng Xu wrote:

On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar  wrote:

hand, but to suggest banning all templates is not a supportable
notion.



Why ?



Because some simple uses of templates are very useful, and
not problematic from any point of view.

Re: pre-compiled versions of GCC for hp-ux

[Jonathan Wakely]

On 17 April 2012 07:55, Mailaripillai, Kannan Jeganathan (STSD) wrote:
>
> I belong to HP-UX Itanium/PA-RISC GCC compiler team. I noticed that the GCC
> page (http://gcc.gnu.org/install/binaries.html) that lists out the
> pre-compiled versions of GCC (for different platforms) does not contain the
> web link of "GCC for HP-UX 11i". Please let me know the procedure to get
> this page updated (under HP-UX section) with the HP web link.

You could just provide the link and ask for it to be changed, but to
be more helpful you could send a patch for the web page.

The GCC web pages are maintained in the old CVS repo, see
http://gcc.gnu.org/cvs.html

If you check out the repo, change the relevant page and then send a
patch to gcc-patc...@gcc.gnu.org and Gerald (CC'd) then all he'll need
to do is apply the patch and check it in.

Re: copyright assignment paperwork?

[Diego Novillo]

On 4/17/12 12:19 AM, Josh Cogliati wrote:

I would like to make a contribution to gcc. What copyright assignment
paperwork do I need to do this and what do I need to get from my
employer?


Sent forms off-list.


Diego.

Re: [x86-64 psABI] Document STT_GNU_IFUNC and R_X86_64_IRELATIVE

[Michael Matz]

Hi,

On Mon, 16 Apr 2012, H.J. Lu wrote:

> Hi Michael,
> 
> Can you apply IFUNC spec to x86-64 psABI?

Yes, ...

> BTW, where can I find the latest x86-64 psABI source? The svn
> site:
> 
> https://www.x86-64.org/svn/trunk/x86-64-ABI
> 
> is down.

... once I find out what the problem with that is :)


Ciao,
Michael.

Why does lower-subreg mark copied pseudos as "decomposable"?

[Andrew Stubbs]

Hi all,

I can see why copying from one pseudo-register to another would not be a 
reason *not* to decompose a register, but I don't understand why this is 
a reason to say it *should* be decomposed.


This is causing me trouble, and I can't tell how to fix it without 
figuring out why it is this way in the first place.


My testcase is from pr43137. This was an ARM missed-optimization bug 
that was fixed some time ago, but has recurred (in my tree) because I'm 
trying to implement SI->DImode extend into 64-bit NEON registers.


Here are the problem insns:

(insn 7 6 8 2 (set (reg:DI 137)
(sign_extend:DI (reg/v:SI 134 [ resultD.4946 ]))) pr43137.c:8
158 {extendsidi2}
 (nil))

(insn 8 7 12 2 (set (reg:DI 136 [  ])
(reg:DI 137)) pr43137.c:8 641 {*movdi_vfp}
 (nil))

(insn 12 8 15 2 (set (reg/i:DI 0 r0)
(reg:DI 136 [  ])) pr43137.c:9 641 {*movdi_vfp}
 (nil))

Lower-subreg thinks it should decompose pseudo 136 because there is a 
pseudo-to-pseudo copy (137->136), even though there is no use of subregs 
here.


The decomposition ends up preventing register allocation from allocating 
r0 to pseudo-137, and we get an unnecessary move emitted and a 
regression of pr43137.



So, why do we have this code?

[lower-subreg.c, find_decomposable_subregs]

case SIMPLE_PSEUDO_REG_MOVE:
  if (MODES_TIEABLE_P (GET_MODE (x), word_mode))
bitmap_set_bit (decomposable_context, regno);
  break;

If I remove these lines my problems go away.

Any clues would be appreciated.

Thanks

Andrew

Re: Wiki slowness

[Steve McIntyre]

Jonathan Wakely wrote:
>Why does saving/editing a page on the GCC wiki take several minutes
>to reload the page?
>
>Opening the page in a new tab shows the changes have been saved, but
>the page still keeps loading. Is there some kind of re-indexing going
>on which is incredibly inefficient?  Or does the moinmoinwiki code
>simply not close the TCP connection or something silly like that?

Looks like the gcc wiki is using the MoinMoin wiki engine, just like
us at wiki.debian.org (where I'm a wiki admin). We've had exactly the
same problem. See

  http://bugs.debian.org/668000

for more details of what I found - it's the time taken to scan the
list of users looking for subscription data. I've just added a patch
into the Debian moin package to add a cache to fix most of the
problems with this. It should backport easily to version 1.8.7 that
you're using. See http://moinmo.in/MoinMoinBugs/GetSubscribersSlow for
one of the upstream moin bug reports, and where I found the patch.

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Re: Why does lower-subreg mark copied pseudos as "decomposable"?

[Richard Sandiford]

Andrew Stubbs  writes:
> Hi all,
>
> I can see why copying from one pseudo-register to another would not be a 
> reason *not* to decompose a register, but I don't understand why this is 
> a reason to say it *should* be decomposed.

The idea is that, if a backend implements an N-word pseudo move using
N word-mode moves, it is better to expose those moves before register
allocation.  It's easier for RA to find N separate word-mode registers
than a single contiguous N-word one.

The problem is the "if a backend implements ..." bit: the current code
doesn't check.  This patch:

http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00094.html

should help.  It's still waiting for me to find a case where the two
possible ways of handling hot-cold partitioning behave differently.

Richard

All maintainers: please note IOR vs OR confusion for atomic_or_* named patterns

[Uros Bizjak]

Hello!

I would like to point out that many targets get atomic_orM named
patterns wrong. The name should be atomic_orM, not atomic_iorM. These
targets are mostly these that were converted from sync named patterns
to atomic ones automatically.

This warning applies to 4.7 branch and current mainline.

Uros.

Re: Why does lower-subreg mark copied pseudos as "decomposable"?

[Andrew Stubbs]

On 17/04/12 18:20, Richard Sandiford wrote:

Andrew Stubbs  writes:

Hi all,

I can see why copying from one pseudo-register to another would not be a
reason *not* to decompose a register, but I don't understand why this is
a reason to say it *should* be decomposed.


The idea is that, if a backend implements an N-word pseudo move using
N word-mode moves, it is better to expose those moves before register
allocation.  It's easier for RA to find N separate word-mode registers
than a single contiguous N-word one.


Ok, I think I understand that, but it seems slightly wrong to me.

It makes sense to lower *real* moves, but before the fwprop pass there 
are quite a lot of pseudos that only exist as artefacts of the expand 
process. Moving the subreg1 pass after fwprop1 would probably do the 
trick, but that would probably also defeat the object of lowering early.


I've done a couple of experiments:

First, I tried adding an extra fwprop pass before subreg1. I needed to 
move up the dfinit pass also to make that work, but then it did work: it 
successfully compiled my testcase without a regression.


I'm not sure that adding an extra pass isn't overkill, so second I tried 
adjusting lower-subreg to avoid this problem; I modified 
find_pseudo_copy so that it rejected copies that didn't change the mode, 
on the principle that fwprop would probably have eliminated the move 
anyway. This was successful also, and a much less expensive change.


Does that make sense? The pseudos involved in the move will still get 
lowered if the other conditions hold.



The problem is the "if a backend implements ..." bit: the current code
doesn't check.  This patch:

 http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00094.html

should help.  It's still waiting for me to find a case where the two
possible ways of handling hot-cold partitioning behave differently.


I've not studied that patch in detail, but I'm not sure it'll help. In 
most cases, including my testcase, lowering is the correct thing to do 
if NEON (or IWMMXT, perhaps) is not enabled. When NEON is enabled, 
however, it may still be the right thing to do: NEON does not provide a 
full set of DImode operations. The test for subreg-only uses ought to be 
enough to differentiate, once the extraneous pseudos such as the one in 
my testcase have been dealt with.


Anyway, please let me know what you think of my solutions above, and 
I'll cook up a patch if they're ok.


Andrew

Re: Switching to C++ by default in 4.8

[Chiheng Xu]

On Tue, Apr 17, 2012 at 2:52 AM, Oleg Endo  wrote:
> On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote:
>> On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu  wrote:
>> >
>> > And I want to say that tree/gimple/rtl are compiler's data(or state),
>> > not compiler's text(or logic), the most important thing about them is
>> > how to access their fields.
>> >
>>
>> Given the above assumption, now I doubt the necessity of accessor
>> macros or C++ getter/setter method.
>
> According to my experience, it doesn't take more time/effort to write
> "tree->code ()" instead of "tree->code" and such getter functions allow
> for easier refactoring etc.  If you omit the getters/setters you can't
> express things such as immutable objects (well you still could with
> const ivars but...), and you'll always have to have the ivar...
>
Sorry,  I don't know what is the benefit of const ivars.
But if you use "tree->code" instead of "tree->code()", the compiler
know very well whether you intend to read or write a piece of memory.
The const-ness is clear. I doubt how the compiler optimizer can
further optimize it.

>>
>> Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or
>> "tree->get_code()" ?
>
> What do you mean by efficient?  All of them will (most likely) end up as
> the same machine code.

By saying "efficient", I probably mean compile time is reduced( macro
expansion + optimizing, or inlining + optimizing, are avoided).
I also probably mean reduced .h file size( the definitions of accessor
macros and C++ getter/setter inline methods, are avoided).

-- 
Chiheng Xu

Re: Wiki slowness

[Jonathan Wakely]

On 17 April 2012 17:51, Steve McIntyre wrote:
> Jonathan Wakely wrote:
>>Why does saving/editing a page on the GCC wiki take several minutes
>>to reload the page?
>>
>>Opening the page in a new tab shows the changes have been saved, but
>>the page still keeps loading. Is there some kind of re-indexing going
>>on which is incredibly inefficient?  Or does the moinmoinwiki code
>>simply not close the TCP connection or something silly like that?
>
> Looks like the gcc wiki is using the MoinMoin wiki engine, just like
> us at wiki.debian.org (where I'm a wiki admin). We've had exactly the
> same problem. See
>
>  http://bugs.debian.org/668000
>
> for more details of what I found - it's the time taken to scan the
> list of users looking for subscription data. I've just added a patch
> into the Debian moin package to add a cache to fix most of the
> problems with this. It should backport easily to version 1.8.7 that
> you're using. See http://moinmo.in/MoinMoinBugs/GetSubscribersSlow for
> one of the upstream moin bug reports, and where I found the patch.

Aha! Thanks for the info.

Re: Switching to C++ by default in 4.8

[Oleg Endo]

On Wed, 2012-04-18 at 06:03 +0800, Chiheng Xu wrote:
> >
> Sorry,  I don't know what is the benefit of const ivars.

I didn't say there's a benefit of using const ivars in this hypothetical
case.  It's just another possible option of doing certain things.

> But if you use "tree->code" instead of "tree->code()", the compiler
> know very well whether you intend to read or write a piece of memory.
> The const-ness is clear. I doubt how the compiler optimizer can
> further optimize it.

I didn't say that either...

> By saying "efficient", I probably mean compile time is reduced( macro
> expansion + optimizing, or inlining + optimizing, are avoided).
> I also probably mean reduced .h file size( the definitions of accessor
> macros and C++ getter/setter inline methods, are avoided).
> 

...then probably I wasn't aware of the fact that this is about
optimizing for compile time.  If that's the case, maybe the topic of the
thread should be changed to avoid further confusion.

Cheers,
Oleg

About sink load from memory in tree-ssa-sink.c

[Bin.Cheng]

Hi,
As discussed at thread
"http://gcc.gnu.org/ml/gcc/2012-04/msg00396.html";, I am trying a patch
now.
The problem here is I have to go through all basic block from
"sink_from" to "sink_to" to check whether
the memory might be clobbered in them.
Currently I have two methods:
1, do fully data analysis to compute the "can_sink" information at
each basic block, which means whether
we can sink a load to a basic block;
2, just compute the transitive closure of CFG, and check any basic
block dominated by "sink_from" and can
reach "sink_to" basic block;

The 2nd method is an approximation, simpler than method 1 but misses
some cases like:

L1:
  load x
L2:
  using x
L3:
  set x
  goto L1

In which, "load x" should be sunk to L2 if there is benefit.

I measured the number of sunk loads during bootstrap gcc for x86,
there are about 732 using method 1, while only 602 using method 2.

So any comment on this topic? Thanks very much.

-- 
Best Regards.