headers
Richard Guenther | 1 Mar 2012 11:09
Picon

Re: IVs optimization issue

On Wed, Feb 29, 2012 at 6:02 PM, Aurelien Buhrig
<aurelien.buhrig.gcc <at> gmail.com> wrote:
> Le 29/02/2012 17:08, Richard Guenther a écrit :
>> On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
>> <aurelien.buhrig.gcc <at> gmail.com> wrote:
>>> Le 29/02/2012 16:15, Richard Guenther a écrit :
>>>> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
>>>> <aurelien.buhrig.gcc <at> gmail.com> wrote:
>>>>>
>>>>>> The issue is most probably that on GIMPLE we only deal with ptr_mode,
>>>>>> not Pmode, and IVOPTs thinks that pointer induction variables will
>>>>>> have ptr_mode.  To fix this the cost computation would need to take
>>>>>> into account ptr_mode to Pmode conversions _and_ would need to
>>>>>> consider Pmode IVs in the first place (I'm not sure that will be easy).
>>>>>
>>>>>
>>>>> Thank you Richard for you reply.
>>>>>
>>>>> I guess such an issue is not in the top priority tasks of main
>>>>> developers. So I think I'll have to look at it myself if I feel
>>>>> confident enough to carry out such a job (I've never worked at tree level).
>>>>>
>>>>> My main wonder is about Pmode IVs: since GIMPLE representation only
>>>>> deals with ptr_mode, what differentiates a Pmode IV from a ptr_mode one?
>>>>
>>>> Its TREE_TYPE.  In your case you'd have a POINTER_TYPE with
>>>> PSImode for Pmode and a POINTER_TYPE with SImode for ptr_mode
>>>> pointers.  They will differ in TYPE_MODE and TYPE_PRECISION.
>>>
>>> Thanks, I will look at it.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Konstantin Vladimirov | 1 Mar 2012 11:50
Picon
Gravatar

register renaming issue

Hi,

I am supporting custom 32-bit backend for gcc 4.6.2, and I want to
implement DI to DF conversion. Earlier it was through libgcc. Specific
of backend is, that DF may be represented as one register, but source
DI must be splitted into two SI to be used.

So overall insn pattern (actual splitting is performed inside expand
pattern) is:

;; splitted 64-bit integer to double float
(define_insn "floatdidf2_32_internal"
  [(parallel
     [(set (subreg:SI (match_operand:DF 0 "register_operand" "=r") 4)
           (subreg:SI (float:DF (match_operand:SI 1 "register_operand" "r")) 4))
      (set (subreg:SI (match_dup 0) 0)
           (subreg:SI (float:DF (match_operand:SI 2 "register_operand"
"r")) 0))])]
  "TARGET_32BIT"
  {
    return output_pseudo_didf(operands);
  }
  [(set_attr "predicable" "no")]
)

output_pseudo_didf is function, that outputs non-trivial instruction
sequence, using operands[0], operands[1], operands[2].

And everything works just fine on -O2, but on -O2 -frename-registers
behaves strange:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aurelien Buhrig | 1 Mar 2012 14:42
Picon

Re: IVs optimization issue

Le 01/03/2012 11:09, Richard Guenther a écrit :
> On Wed, Feb 29, 2012 at 6:02 PM, Aurelien Buhrig
> <aurelien.buhrig.gcc <at> gmail.com> wrote:
>> Le 29/02/2012 17:08, Richard Guenther a écrit :
>>> On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
>>> <aurelien.buhrig.gcc <at> gmail.com> wrote:
>>>> Le 29/02/2012 16:15, Richard Guenther a écrit :
>>>>> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
>>>>> <aurelien.buhrig.gcc <at> gmail.com> wrote:
>>>>>>
>>>>>>> The issue is most probably that on GIMPLE we only deal with ptr_mode,
>>>>>>> not Pmode, and IVOPTs thinks that pointer induction variables will
>>>>>>> have ptr_mode.  To fix this the cost computation would need to take
>>>>>>> into account ptr_mode to Pmode conversions _and_ would need to
>>>>>>> consider Pmode IVs in the first place (I'm not sure that will be easy).
>>>>>>
>>>>>>
>>>>>> Thank you Richard for you reply.
>>>>>>
>>>>>> I guess such an issue is not in the top priority tasks of main
>>>>>> developers. So I think I'll have to look at it myself if I feel
>>>>>> confident enough to carry out such a job (I've never worked at tree level).
>>>>>>
>>>>>> My main wonder is about Pmode IVs: since GIMPLE representation only
>>>>>> deals with ptr_mode, what differentiates a Pmode IV from a ptr_mode one?
>>>>>
>>>>> Its TREE_TYPE.  In your case you'd have a POINTER_TYPE with
>>>>> PSImode for Pmode and a POINTER_TYPE with SImode for ptr_mode
>>>>> pointers.  They will differ in TYPE_MODE and TYPE_PRECISION.
>>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Guenther | 1 Mar 2012 15:21
Picon

Re: Graphite news

On Thu, Feb 9, 2012 at 1:42 PM, Tobias Grosser <tobias <at> grosser.es> wrote:
> Hi,
>
> it has been quiet around Graphite for a while and I think it is more than
> time to give an update on Graphite.
>
> == The Status of Graphite ==
>
> Graphite has been around for a while in GCC. During this time a lot of
> people tested Graphite and Sebastian fixed many bugs. As of today the
> Graphite infrastructure is pretty stable and hosts already specific
> optimizations such as loop-interchange, blocking and loop-flattening.
>
> However, during the development of Graphite we also found areas where
> we are still way behind our possibilities.
> First of all we realized that the use of a rational polyhedral library, even
> though it provides some functionality for integer polyhedra, is blocking us.
> Rational rational polyhedra worked OK for some time, but we have now come to
> a point where the absence of real integer polyhedra is causing problems. We
> have bugs that cannot be solved, just because rational polyhedra do not
> represent correctly the set of integer points in the loop iterations.
> Another deficit in Graphite is the absence of a generic optimizer. Even
> though classical loop transformations work well for certain problems, one of
> the major selling points of polyhedral techniques is the possibility to go
> beyond classical loop transformations and to forget about the corresponding
> pass ordering issues. Instead it is possible to define a generic cost
> function for which to optimize. We currently do not take advantage of this
> possibility and therefore miss possible performance gains.
> And as a last point, Graphite still does not apply to as much code as it
> could. We cannot transform a lot of code, not only because of the missing
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bin.Cheng | 1 Mar 2012 15:45
Picon

Re: RFC: Handle conditional expression in sccvn/fre/pre

>> Second point, as you said, PRE often get confused and moves compare
>> EXPR far from jump statement. Could we rely on register re-materialize
>> to handle this, or any other solution?
>
> Well, a simple kind of solution would be to preprocess the IL before
> redundancy elimination and separate the predicate computation from
> their uses and then as followup combine predicates back (tree forwprop
> would do that, for example - even for multiple uses).  The question is
> what you gain in the end.

I realized there is no merit if compare EXPR is factored only for PRE pass.

>
>> I would like to learn more about this case, so do you have any opinion on
>> how this should be fixed for now.
>
> The GIMPLE IL should be better here, especially if you consider that
> we force away predicate computation that may trap for -fnon-call-exceptions
> already.  So, simplifying the IL is still the way to go IMHO.  But as I said
> above - it's a non-trivial task with possibly much fallout.
>
There is another benefit. Currently general compare EXPR is a dead case GCC
can not handle in conditional const/copy propagation. It can be handled properly
after rewriting, since GIMPLE_COND only contains a predicate SSA_NAME.
For example, redundant gimple generated for test case in pr38998:

<bb 2>:
  if (y_3(D) < 1.0e+1)
    goto <bb 8>;
  else
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Guenther | 1 Mar 2012 16:22
Picon

Re: RFC: Handle conditional expression in sccvn/fre/pre

On Thu, Mar 1, 2012 at 3:45 PM, Bin.Cheng <amker.cheng <at> gmail.com> wrote:
>>> Second point, as you said, PRE often get confused and moves compare
>>> EXPR far from jump statement. Could we rely on register re-materialize
>>> to handle this, or any other solution?
>>
>> Well, a simple kind of solution would be to preprocess the IL before
>> redundancy elimination and separate the predicate computation from
>> their uses and then as followup combine predicates back (tree forwprop
>> would do that, for example - even for multiple uses).  The question is
>> what you gain in the end.
>
> I realized there is no merit if compare EXPR is factored only for PRE pass.
>
>>
>>> I would like to learn more about this case, so do you have any opinion on
>>> how this should be fixed for now.
>>
>> The GIMPLE IL should be better here, especially if you consider that
>> we force away predicate computation that may trap for -fnon-call-exceptions
>> already.  So, simplifying the IL is still the way to go IMHO.  But as I said
>> above - it's a non-trivial task with possibly much fallout.
>>
> There is another benefit. Currently general compare EXPR is a dead case GCC
> can not handle in conditional const/copy propagation. It can be handled properly
> after rewriting, since GIMPLE_COND only contains a predicate SSA_NAME.
> For example, redundant gimple generated for test case in pr38998:
>
> <bb 2>:
>  if (y_3(D) < 1.0e+1)
>    goto <bb 8>;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jakub Jelinek | 1 Mar 2012 16:26
Picon
Favicon

GCC 4.6.3 Released

The GNU Compiler Collection version 4.6.3 has been released.

GCC 4.6.3 is a bug-fix release containing fixes for regressions and serious
bugs in GCC 4.6.2, with over 70 bugs fixed since previous release.  This
release is available from the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments about
this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release -- far
too many to thank individually!
Permalink | Reply | 0 comments |
headers
gccadmin | 1 Mar 2012 23:49
Picon
Favicon

gcc-4.5-20120301 is now available

Snapshot gcc-4.5-20120301 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120301/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 184762

You'll find:

 gcc-4.5-20120301.tar.bz2             Complete GCC

  MD5=f42ee096cd501240c9b7eba60961df21
  SHA1=941f3b275de21fea5a8438fafb4bf71fd20c43ed

Diffs from 4.5-20120223 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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.
Permalink | Reply | 0 comments |
headers
Dan Towner | 2 Mar 2012 11:49
Favicon

Query about DWARF output for recursively nested inlined subroutines

Hi all,

I have noticed the following construct appearing in some DWARF output and
I'm don't understand what it means, or whether it is actually a bug:

        .uleb128 0x1c   ;# (DIE (0x80a) DW_TAG_inlined_subroutine)
        .long 0x635        ;# DW_AT_abstract_origin
        .word _picoMark_LBB23      ;# DW_AT_low_pc
        .word _picoMark_LBE23      ;# DW_AT_high_pc
        .byte 0x1   ;# DW_AT_call_file
(/home/dant/Tools/Verification/Flow/standalone_fn_error.vhd)
        .byte 0xaf  ;# DW_AT_call_line
        .uleb128 0x17   ;# (DIE (0x815) DW_TAG_formal_parameter)
        .long 0x650        ;# DW_AT_abstract_origin
        .long _picoMark_LLST15     ;# DW_AT_location
        .uleb128 0x1c   ;# (DIE (0x81e) DW_TAG_inlined_subroutine)
        .long 0x635        ;# DW_AT_abstract_origin
        .word _picoMark_LBB25      ;# DW_AT_low_pc
        .word _picoMark_LBE25      ;# DW_AT_high_pc
        .byte 0x1   ;# DW_AT_call_file
(/home/dant/Tools/Verification/Flow/standalone_fn_error.vhd)
        .byte 0x47  ;# DW_AT_call_line
        .uleb128 0x17   ;# (DIE (0x829) DW_TAG_formal_parameter)
        .long 0x650        ;# DW_AT_abstract_origin
        .long _picoMark_LLST16     ;# DW_AT_location
        .uleb128 0x1e   ;# (DIE (0x832) DW_TAG_lexical_block)
        .word _picoMark_LBB26      ;# DW_AT_low_pc
        .word _picoMark_LBE26      ;# DW_AT_high_pc

There are two puzzling things about this little fragment. Firstly the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Guenther | 2 Mar 2012 12:15
Picon

GCC 4.7.0 Status Report (2012-03-02)


The GCC 4.7 branch has been created and a first release candidate
is being prepared right now.  The branch is closed for now.

Previous Report
===============

http://gcc.gnu.org/ml/gcc/2012-02/msg00441.html

The next report will announce the release candidate.
Permalink | Reply | 2 comments |

Gmane