Re: Question on updating DF info during code hoisting

[Steven Bosscher]

On Tue, Oct 23, 2012 at 5:17 AM, Bin.Cheng wrote:
> Thanks for your explanation.
> Now I understand how df_insn_info is updated when
> deleting/modifying/creating insn. One more question is when and how
> IN/OUT information is updated. GCC calls df_set_bb_dirty when handling
> insns, but I did not found any spot in GCSE updating that information.
> is it done in CFG_CLEANUP?

It is done lazily in any call to df_analyze.

> I would like to study DF infrastructure later, could you share some
> background knowledge on this, for example theory/algorithms to which
> GCC referred. Though there is good comment at the beginning of
> df-core.c, it doesn't mention any background/references.

The stuff in df-problems.c is mostly just Dragon book stuff. For the
solver itself there is a reference to a paper from Harvey IIRC, but
this is also mostly just Dragon book or Muchnick stuff. The only
"fancy" stuff would be how several classic problems are combined. For
example, DF_LIVE is actually a combination of "classic" liveness and
partial availability. Likewise for the pruned version of reaching
definitions. The MD problem is probably not described anywhere, but
it's basically poor-man's SSA.

The scan problem and data structures are compiler specific. I don't
think there are any documented theories about this, it's too specific
because all of it is strongly bound to how the compiler's internal
representation is constructed. The DF infrastructure supports (or
works around, depending on your POV) the RTL representation with
on-the-side operand caches. Other compilers or internal
representations may not need that (e.g. GIMPLE operand caches are on
the GIMPLE statement themselves). The documentation in the code is
quite good, but if you have any specific questions then there's always
this mailing list :-)

Ciao!
Steven

Re: VN_INFO might be NULL in PRE

[Richard Biener]

On Tue, Oct 23, 2012 at 7:36 AM, Zhenqiang Chen
 wrote:
> Hi,
>
> PRE bases on the result of value numbering (run_scc_vn). At the end,
> it free_scc_vn. But before free_scc_vn, it might call cleanup_tree_cfg
> ();
>
>   if (do_eh_cleanup || do_ab_cleanup)
> cleanup_tree_cfg ();
>
> cleanup_tree_cfg might call make_ssa_name which might reuse some
> "name" from the FREE_SSANAMES list. If the VN_INFO of the "name" is
> NULL, free_scc_vn will "Segmentation fault". PR 54902
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54902) shows a real case.
> The attached log shows the gdb backtrace to create a new ssa name.
>
> Here is function VN_INFO:
>
> vn_ssa_aux_t
> VN_INFO (tree name)
> {
>   vn_ssa_aux_t res = VEC_index (vn_ssa_aux_t, vn_ssa_aux_table,
> SSA_NAME_VERSION (name));
>   gcc_checking_assert (res);
>   return res;
> }
>
> Can we make sure "res" is not NULL for the new ssa name?
>
> In trunk, Richard's "Make gsi_remove return whether EH cleanup is
> required" patches in r186159 and r186164 make "do_eh_cleanup" to
> false. So cleanup_tree_cfg is not called in PRE. Then no new ssa name
> will be created.
>
> Does the Richard's patch fix the root cause?

I don't think so.  Where does cfgcleanup call make_ssa_name?  The solution
would be to post-pone cleaning up the CFG until after free_ssc_vn.  To
be able to compute dominators we only have to remove unreachable blocks
(delete_unreachable_blocks)

Richard.

> Thanks!
> -Zhenqiang

Documentation problem with TEXT_SECTION_ASM_OP

[Paulo Matos]

Hi,

TEXT_SECTION_ASM_OP doc says:
"A C expression whose value is a string, including spacing, containing the 
assembler operation that should precede instructions and read-only data."

However, crtstuff.c uses `asm(TEXT_SECTION_ASM_OP)'.

I am trying to use a C expression for TEXT_SECTION_ASM_OP like:
#define TEXT_SECTION_ASM_OP (arch == "v2" ? "\t.section .text, \"ax\"" : 
"\t.section .textc, \"axz\"")

This seems to be valid according to the docs but fails to compile crtstuff.c 
since TEXT_SECTION_ASM_OP should be a string literal to be used with asm.
Since this is most likely a problem with the docs, how can I achieve something 
like this and have only a string literal as value or TEXT_SECTION_ASM_OP?

Cheers,

Paulo Matos

RE: Documentation problem with TEXT_SECTION_ASM_OP

[Paulo Matos]

I just noticed at the top of Sections.html in gccint:
The normal way of controlling a foo_section variable is to define the 
associated FOO_SECTION_ASM_OP macro, as described below.  The macros are only 
read once, when varasm.c initializes itself, so their values must be run-time 
constants.

This sentence is quite confusing. 'their values must be run-time constants' 
means that it can only depend on gcc's compile time flags? Or can it depend on 
gcc's command line arguments (for example)? I guess what's confusing me is 
'when varasm.c initializes itself'. Does this happen after gcc command line 
arguments are read or at gcc's compile time?

Paulo Matos


> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Paulo Matos
> Sent: 23 October 2012 12:08
> To: gcc@gcc.gnu.org
> Subject: Documentation problem with TEXT_SECTION_ASM_OP
> 
> Hi,
> 
> TEXT_SECTION_ASM_OP doc says:
> "A C expression whose value is a string, including spacing, containing the
> assembler operation that should precede instructions and read-only data."
> 
> However, crtstuff.c uses `asm(TEXT_SECTION_ASM_OP)'.
> 
> I am trying to use a C expression for TEXT_SECTION_ASM_OP like:
> #define TEXT_SECTION_ASM_OP (arch == "v2" ? "\t.section .text, \"ax\"" :
> "\t.section .textc, \"axz\"")
> 
> This seems to be valid according to the docs but fails to compile crtstuff.c
> since TEXT_SECTION_ASM_OP should be a string literal to be used with asm.
> Since this is most likely a problem with the docs, how can I achieve something
> like this and have only a string literal as value or TEXT_SECTION_ASM_OP?
> 
> Cheers,
> 
> Paulo Matos
> 
> 
> 

RE: Documentation problem with TEXT_SECTION_ASM_OP

[Paulo Matos]

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Paulo Matos
> Sent: 23 October 2012 14:47
> To: gcc@gcc.gnu.org
> Subject: RE: Documentation problem with TEXT_SECTION_ASM_OP
> 
> This sentence is quite confusing. 'their values must be run-time constants'
> means that it can only depend on gcc's compile time flags? Or can it depend
> on gcc's command line arguments (for example)? I guess what's confusing
> me is 'when varasm.c initializes itself'. Does this happen after gcc command
> line arguments are read or at gcc's compile time?
> 

Should have kept reading:
"They may however depend on command-line flags."

if-conversion/HOT-COLD partitioning

[Christophe Lyon]

Hi,

While debugging a GCC failure on ARM when compiling with
-fprofile-use, I came across a case where if_convert merges 2 blocks
which belong to different partitions (hot/cold).

In turn merge_blocks() (in cfghooks.c) merges the BB flags by ORing
them, resulting in a block belonging to both cold and hot partitions,
which seems to confuse the compiler: for instance in
bb-reorder.c:connect_traces(), the code expects only one partition
flag to be set.

I think merge_blocks() should be modified to handle such cases; I
experimented a little and forcing the merged BB's partition to be the
hot one in such a case is not sufficient: some edges have been marked
as crossing ones, and this would be no longer true. Is there a simple
way to clean that?

Thanks,

Christophe.

Re: Documentation problem with TEXT_SECTION_ASM_OP

[Joseph S. Myers]

On Tue, 23 Oct 2012, Paulo Matos wrote:

> Since this is most likely a problem with the docs, how can I achieve 
> something like this and have only a string literal as value or 
> TEXT_SECTION_ASM_OP?

At  I listed this 
macro, and lots of others, under "used by the compiler itself and libgcc 
(probably predefine macros if -fbuilding-libgcc in most cases, unless 
predefined macros considered more generally useful)".  I think that 
approach still makes sense for improving the host / target tm.h 
separation: use these tm.h macros directly only in the compiler, and make 
the compiler, if -fbuilding-libgcc, predefine a macro for use in GCC's own 
libraries.

So far only TRAMPOLINE_SIZE is handled like that; conversions of other 
macros are welcome.  The list on that wiki page may be a bit out of date, 
but should still be a good starting point for this project.

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

bugzilla vs. MAINTAINERS

[Joern Rennecke]

Could we make bugzilla recognize all the email addresses in the MAINTAINERs
file?  It is frustrating to identify the maintainer of the piece that's
broken, only to find that bugzilla will refuse to add the person the the CC
list.  This affects a number of the sub PRs of PR47093 / PR44756 ,
which is why they have an empty CC list.

Re: bugzilla vs. MAINTAINERS

[Richard Biener]

On Tue, Oct 23, 2012 at 4:37 PM, Joern Rennecke
 wrote:
> Could we make bugzilla recognize all the email addresses in the MAINTAINERs
> file?  It is frustrating to identify the maintainer of the piece that's
> broken, only to find that bugzilla will refuse to add the person the the CC
> list.  This affects a number of the sub PRs of PR47093 / PR44756 ,
> which is why they have an empty CC list.

Can we instead make it sort @gcc.gnu.org accounts first when it asks to confirm
a CC member?  Hard to pick the correct person from all the noise ... (if you
happen to not remember the exact match).

Richard.

Re: bugzilla vs. MAINTAINERS

[Joern Rennecke]

Quoting Richard Biener :

Can we instead make it sort @gcc.gnu.org accounts first when it asks  
 to confirm

a CC member?  Hard to pick the correct person from all the noise ... (if you
happen to not remember the exact match).


Well, that'd be all right with me, but if there is no @gcc.gnu.org address
that matches the address listed in MAINTAINERS, it should allow the address
from MAINTAINERS.  Of course, if there is a @gcc.gnu.org address for that
person that bugzilla somehow fails to find, I'd rather have it find that.

RE: Documentation problem with TEXT_SECTION_ASM_OP

[Paulo Matos]

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Joseph S. Myers
> Sent: 23 October 2012 15:28
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Documentation problem with TEXT_SECTION_ASM_OP
> 
> At  I listed this
> macro, and lots of others, under "used by the compiler itself and libgcc
> (probably predefine macros if -fbuilding-libgcc in most cases, unless
> predefined macros considered more generally useful)".  I think that
> approach still makes sense for improving the host / target tm.h
> separation: use these tm.h macros directly only in the compiler, and make
> the compiler, if -fbuilding-libgcc, predefine a macro for use in GCC's own
> libraries.
> 

If this -fbuilding-libgcc being passed at current HEAD? I am looking at 4.7 and 
no flag like that
Is being passed while building libgcc.

My problem still remains. On the docs it says:
You must always create a text_section, either by defining TEXT_SECTION_ASM_OP 
or by initializing text_section in TARGET_ASM_INIT_SECTIONS.

My text_section text is different depending on gcc flags. I can use 
TARGET_ASM_INIT_SECTIONS to initialize text_section but once I get to 
crtstuff.c I still need a TEXT_SECTION_ASM_OP.

Since we are building the libraries, unfortunately I can't access text_section 
anymore from my libgcc target header. Any suggestions on how to get around this 
problem?

-- 
Paulo Matos

RE: Documentation problem with TEXT_SECTION_ASM_OP

[Joseph S. Myers]

On Tue, 23 Oct 2012, Paulo Matos wrote:

> If this -fbuilding-libgcc being passed at current HEAD? I am looking at 
> 4.7 and no flag like that Is being passed while building libgcc.

It's in LIBGCC2_CFLAGS in libgcc/Makefile.in in both 4.7 and trunk.

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

Re: bugzilla vs. MAINTAINERS

[Jonathan Wakely]

On 23 October 2012 15:58, Joern Rennecke wrote:
>
> Well, that'd be all right with me, but if there is no @gcc.gnu.org address
> that matches the address listed in MAINTAINERS, it should allow the address
> from MAINTAINERS.  Of course, if there is a @gcc.gnu.org address for that
> person that bugzilla somehow fails to find, I'd rather have it find that.

But usually the name will match, so if you type the maintainer's name
and let bugzilla search it will show you the valid addresses for that
person.

alias template bug?

[Andrew Sutton]

I just updated to GCC from trunk (r192711) and started getting some
peculiar errors. In particular, GCC seems to believe that sizeof(T) is
no longer a constant when used as an argument to an alias template.
Here's the smallest reproduction I can create with the relevant error:


template
  struct type { };

template
  using alias = type;

template 
  struct use
  {
alias member; // <-- error: integral expression ‘sizeof
(T)’ is not constant
  };

This happens with arguments including alignof(), and various
__type_traits() also. Replacing the errant declaration with
"type" works fine. It looks like this problem may have been
introduced during a change to instantiate template aliases inside
template definitions, because I wasn't getting this behavior in my
previous version (~1 month old? 2?).

Andrew Sutton
andrew.n.sut...@gmail.com

Re: alias template bug?

[Marc Glisse]

On Tue, 23 Oct 2012, Andrew Sutton wrote:


I just updated to GCC from trunk (r192711) and started getting some
peculiar errors. In particular, GCC seems to believe that sizeof(T) is
no longer a constant when used as an argument to an alias template.


I think Jakub just fixed that one an hour ago or so.

--
Marc Glisse

Re: alias template bug?

[Andrew Sutton]

>> I just updated to GCC from trunk (r192711) and started getting some
>> peculiar errors. In particular, GCC seems to believe that sizeof(T) is
>> no longer a constant when used as an argument to an alias template.
>
> I think Jakub just fixed that one an hour ago or so.

And committed the changes? I just updated (r192742) and am getting the
same errors. Are these the relevant bug reports?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54912
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859

Andrew

Re: if-conversion/HOT-COLD partitioning

[Christophe Lyon]

On 23 October 2012 19:45, Steven Bosscher  wrote:
> Christophe wrote:
>> I think merge_blocks() should be modified to handle such cases;
>
> I think can_merge_blocks should be fixed. Blocks from different
> partitions should not be merged. See cfgrtl.c:rtl_can_merge_blocks and
> cfgrtl.c:cfg_layout_can_merge_blocks_p. Why are they not blocking
> these blocks from getting merged?
>

Well, both of these functions appear to check that the 2 blocks to
merge belong to the same partition, so it should be OK.

But not all calls to merge_blocks are guarded by if
(can_merge_block_p()), this is probably where the problem is?

Christophe.

Re: alias template bug?

[Marc Glisse]

On Tue, 23 Oct 2012, Andrew Sutton wrote:


I just updated to GCC from trunk (r192711) and started getting some
peculiar errors. In particular, GCC seems to believe that sizeof(T) is
no longer a constant when used as an argument to an alias template.


I think Jakub just fixed that one an hour ago or so.


And committed the changes? I just updated (r192742) and am getting the
same errors.


Ah, I must have gotten confused with:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54844

Sorry...

--
Marc Glisse

Re: alias template bug?

[Paolo Carlini]

.. right now I can't really check, but looks like 54912 & co

Paolo

Re: if-conversion/HOT-COLD partitioning

[Steven Bosscher]

On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon
 wrote:
> Well, both of these functions appear to check that the 2 blocks to
> merge belong to the same partition, so it should be OK.

In your first email, you said if-convert was merging two blocks from
different partitions. can_merge_block_p() would rejected merging the
two blocks, so merge_blocks shouldn't be called on them.

IIRC cfghooks.c:merge_blocks() used to have a
gcc_assert(can_merge_blocks(a,b)) but it's not there now. But if
can_merge_blocks() returns false, merge_blocks should fail. Your bug
is that merge_blocks is being called at all on those blocks from
different partitions.


> But not all calls to merge_blocks are guarded by if
> (can_merge_block_p()), this is probably where the problem is?

Not sure. Depends on what blocks get merged. It may be that
if-conversion shouldn't even be attempting whatever transformation
it's attempting. Not enough information.

Ciao!
Steven

Re: VN_INFO might be NULL in PRE

[Zhenqiang Chen]

On 23 October 2012 18:02, Richard Biener  wrote:
> On Tue, Oct 23, 2012 at 7:36 AM, Zhenqiang Chen
>  wrote:
>> Hi,
>>
>> PRE bases on the result of value numbering (run_scc_vn). At the end,
>> it free_scc_vn. But before free_scc_vn, it might call cleanup_tree_cfg
>> ();
>>
>>   if (do_eh_cleanup || do_ab_cleanup)
>> cleanup_tree_cfg ();
>>
>> cleanup_tree_cfg might call make_ssa_name which might reuse some
>> "name" from the FREE_SSANAMES list. If the VN_INFO of the "name" is
>> NULL, free_scc_vn will "Segmentation fault". PR 54902
>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54902) shows a real case.
>> The attached log shows the gdb backtrace to create a new ssa name.
>>
>> Here is function VN_INFO:
>>
>> vn_ssa_aux_t
>> VN_INFO (tree name)
>> {
>>   vn_ssa_aux_t res = VEC_index (vn_ssa_aux_t, vn_ssa_aux_table,
>> SSA_NAME_VERSION (name));
>>   gcc_checking_assert (res);
>>   return res;
>> }
>>
>> Can we make sure "res" is not NULL for the new ssa name?
>>
>> In trunk, Richard's "Make gsi_remove return whether EH cleanup is
>> required" patches in r186159 and r186164 make "do_eh_cleanup" to
>> false. So cleanup_tree_cfg is not called in PRE. Then no new ssa name
>> will be created.
>>
>> Does the Richard's patch fix the root cause?
>
> I don't think so.  Where does cfgcleanup call make_ssa_name?  The solution
> would be to post-pone cleaning up the CFG until after free_ssc_vn.  To
> be able to compute dominators we only have to remove unreachable blocks
> (delete_unreachable_blocks)

The attachment (bt.log) in previous mail shows the trace to call
make_ssa_name. PR 54902 includes a test case to reproduce it. The
bt.log bases on 4.7.

I have no case to reproduce it for trunk. But cleanup_tree_cfg is
still called before free_ssc_vn.

Thanks!
-Zhenqiang