Re: How to generate jump_table_data in rtl optimizers

[Jeff Law]

On 11/08/2015 11:20 PM, Bin.Cheng wrote:

Hi,
I used below code snippet to generate jump_table_data:

//setup label refs
start_sequence ();
emit_jump_table_data(gen_rtx_
ADDR_DIFF_VEC (CASE_VECTOR_MODE,

 base_label_ref,

 label_refs...))
insns = get_insns ();
end_sequence ();
split_edge_and_insert (edge, insns);

Don't put it onto a sequence and see if that helps.



But later on GCC exited with below error message:

xxx.c:15:1: error: unrecognizable insn:
  }
  ^
(insn 187 109 113 3 (jump_table_data 185 0 0 (addr_diff_vec:DI
(label_ref:DI 184)
  [
 (label_ref:DI 178)
 (label_ref:DI 179)
 (label_ref:DI 180)
 (label_ref:DI 181)
 (label_ref:DI 182)
 (label_ref:DI 183)
 (label_ref:DI 184)
 ]
 (const_int 0 [0])
 (const_int 0 [0]))) -1
  (nil))
xxx.c:15:1: internal compiler error: in extract_insn, at recog.c:2286

You don't want the outer insn.



Seems what GCC expecting is as below:

(jump_table_data 185 0 0 (addr_diff_vec:DI (label_ref:DI 184)
  [
 (label_ref:DI 178)
 (label_ref:DI 179)
 (label_ref:DI 180)
 (label_ref:DI 181)
 (label_ref:DI 182)
 (label_ref:DI 183)
 (label_ref:DI 184)
 ]
 (const_int 0 [0])
 (const_int 0 [0])))

Right.
/


The outer insn structure is created in emit_insn_after and make_insn_raw.

I looked into stmt.c:emit_case_dispatch_table, seems GCC used
record_insns there, and it only inserts insn to list, and does not
create the outer insn structure.

Since record_insns/record_insns_nobb are deprecated according to
comments, my question is how to generate jump_table_data then?  Is
jump_table_data not supported in emit_insn_*?

I presume you mean reorder_insns not record_insns :-)

I'd start by using reorder_insns to make sure you have your other logic 
right, then look to eliminate its use.


jeff

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote:
> It seems like a doc update is what is needed to close PR24414 (Old-style 
> asms don't clobber memory).

What is needed to close the bug is to make the compiler work properly.

Whether that means clobbering memory or not, I don't much care -- with
the status quo, if you want your asm to clobber memory you have to use
extended asm; if basic asm is made to clobber memory, if you want your
asm to *not* clobber memory you have to use extended asm (which you
can with no operands by writing e.g.  asm("bork" : );  ).  So both
behaviours are available whether we make a change or not.

But changing things now will likely break user code.

>  Safely accessing C data and calling functions from basic @code{asm} is more 
> -complex than it may appear. To access C data, it is better to use extended 
> +complex than it may appear. To access C data (including both local and
> +global register variables), use extended
>  @code{asm}.

I don't think this makes things clearer.  Register vars are described
elsewhere already; if you really think it needs mentioning here, put
it at the end (in its own sentence), don't break up this sentence.

(dot space space).

> +Basic @code{asm} statements are not treated as though they used a "memory"
> +clobber, although they do implicitly perform a clobber of the flags
> +(@pxref{Clobbers}).

They do not clobber the flags.  Observe:

===
void f(int a)
{
a = a >> 2;
if (a <= 0)
asm("OHAI");
if (a >= 0)
asm("OHAI2");
}
===

Compiling this for powerpc gives (-m32, edited):

f:
srawi. 9,3,2# this sets cr0
ble 0,.L5   # this uses cr0
.L2:
OHAI2
blr
.p2align 4,,15
.L5:
OHAI
bnelr 0 # this uses cr0
b .L2

which shows that CR0 (which is "cc") is live over the asm.  So are all
other condition regs.

It is true for cc0 targets I guess, but there aren't many of those left.

> Also, there is no implicit clobbering of registers,
> +so any registers changed must be restored to their original value before
> +exiting the @code{asm}.

One of the important uses of asm is to set registers GCC does not know
about, so you might want to phrase this differently.


Segher

Re: inline asm and multi-alternative constraints

[Richard Earnshaw]

On 07/11/15 09:23, Segher Boessenkool wrote:
> On Fri, Nov 06, 2015 at 11:50:40PM -0800, David Wohlferd wrote:
>>> The same goes for some constraints and almost all output modifiers.
>>
>> Are you suggesting more doc changes?  Looking thru the pages you reference:
>>
>> - Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable 
>> for inline asm.  But both "#*" seem sketchy.
> 
> Output modifiers, not constraint modifiers -- things like "%X0" in
> the output template.  Many are only useful in the machine description,
> but some (like that 'X' for rs6000) are vital for asm as well.
> 

They're not just useful, they're essential on AArch64 and ARM.  They're
needed, for example, to get the 32/64-bit register sizing correct.

R.

>> - Under 'simple constraints', "mringX" all (more or less) make sense to 
>> me.  But "oV<>sp" are not things I can envision using.
> 
> Some are more useful on some targets than on others, sure.  But these
> generic constraints are extremely unlikely to ever get a change; this
> is not true for target constraints.  If we want to delete (or change
> semantics of) some target constraint, and that constraint is documented,
> we have to fear the ire of the one or two users of that constraint.
> 
>> - The 'machine constraints' for i386 (the only machine I know) all seem 
>> reasonable.  However for platforms that support autoincrement 
>> (powerpc?), apparently using "m" needs more docs (per 
>> https://gcc.gnu.org/ml/gcc/2008-03/msg01079.html).
> 
> I think the manual (the "Simple Constraints" section) does describe it
> all, but it could be clearer.  The PowerPC 'm' description does a good
> job of explaining things further (for that target).
> 
>> Are these the things to which you are referring?  I've always assumed 
>> the parts that seem obscure here were due to my i386-centric view of the 
>> world.  Are some of them actually md-only?
> 
> Almost everything can be used in asm as well, but many constraints etc.
> are much less useful there.
> 
>> There are other minor changes I'd make on some of these pages.  But 
>> mostly they are not worth it unless I'm doing something else there too.  
>> So if there's something here you think needs changing, let me know and 
>> I'll take a crack at it.
>>
>> Other than that, I'll keep working my way thru the doc issues in the 
>> inline-asm bugs.  I've done what I can for 10396.
> 
> Thanks again :-)
> 
> 
> Segher
> 

Re: inline asm and multi-alternative constraints

[Richard Earnshaw]

On 09/11/15 09:57, Richard Earnshaw wrote:
> On 07/11/15 09:23, Segher Boessenkool wrote:
>> On Fri, Nov 06, 2015 at 11:50:40PM -0800, David Wohlferd wrote:
 The same goes for some constraints and almost all output modifiers.
>>>
>>> Are you suggesting more doc changes?  Looking thru the pages you reference:
>>>
>>> - Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable 
>>> for inline asm.  But both "#*" seem sketchy.
>>
>> Output modifiers, not constraint modifiers -- things like "%X0" in
>> the output template.  Many are only useful in the machine description,
>> but some (like that 'X' for rs6000) are vital for asm as well.
>>
> 
> They're not just useful, they're essential on AArch64 and ARM.  They're
> needed, for example, to get the 32/64-bit register sizing correct.
> 

On the other hand, we have %S on ARM which cannot ever be used from
inline assembler: it matches the result of a match_operator rule with
complex internal structure that could never be generated from user code.

> R.
> 
>>> - Under 'simple constraints', "mringX" all (more or less) make sense to 
>>> me.  But "oV<>sp" are not things I can envision using.
>>
>> Some are more useful on some targets than on others, sure.  But these
>> generic constraints are extremely unlikely to ever get a change; this
>> is not true for target constraints.  If we want to delete (or change
>> semantics of) some target constraint, and that constraint is documented,
>> we have to fear the ire of the one or two users of that constraint.
>>
>>> - The 'machine constraints' for i386 (the only machine I know) all seem 
>>> reasonable.  However for platforms that support autoincrement 
>>> (powerpc?), apparently using "m" needs more docs (per 
>>> https://gcc.gnu.org/ml/gcc/2008-03/msg01079.html).
>>
>> I think the manual (the "Simple Constraints" section) does describe it
>> all, but it could be clearer.  The PowerPC 'm' description does a good
>> job of explaining things further (for that target).
>>
>>> Are these the things to which you are referring?  I've always assumed 
>>> the parts that seem obscure here were due to my i386-centric view of the 
>>> world.  Are some of them actually md-only?
>>
>> Almost everything can be used in asm as well, but many constraints etc.
>> are much less useful there.
>>
>>> There are other minor changes I'd make on some of these pages.  But 
>>> mostly they are not worth it unless I'm doing something else there too.  
>>> So if there's something here you think needs changing, let me know and 
>>> I'll take a crack at it.
>>>
>>> Other than that, I'll keep working my way thru the doc issues in the 
>>> inline-asm bugs.  I've done what I can for 10396.
>>
>> Thanks again :-)
>>
>>
>> Segher
>>
> 

Re: [RFC PR43721] Optimize a/b and a%b to single divmod call

[Prathamesh Kulkarni]

On 4 November 2015 at 20:35, Richard Biener  wrote:
> On Wed, 4 Nov 2015, Prathamesh Kulkarni wrote:
>
>> On 2 November 2015 at 18:31, Richard Biener  wrote:
>> > On Mon, 2 Nov 2015, Prathamesh Kulkarni wrote:
>> >
>> >> On 2 November 2015 at 13:20, Prathamesh Kulkarni
>> >>  wrote:
>> >> > On 30 October 2015 at 15:57, Richard Biener 
>> >> >  wrote:
>> >> >> On Fri, Oct 30, 2015 at 8:39 AM, Prathamesh Kulkarni
>> >> >>  wrote:
>> >> >>> Hi,
>> >> >>> I have attached revamped version of Kugan's patch
>> >> >>> (https://gcc.gnu.org/ml/gcc/2013-06/msg00100.html) for PR43721.
>> >> >>> Test-case: http://pastebin.com/QMfpXLD9
>> >> >>> divmod pass dump: http://pastebin.com/yMY1ikCp
>> >> >>> Assembly: http://pastebin.com/kk2HZpvA
>> >> >>>
>> >> >>> The approach I took is similar to sincos pass, which involves two 
>> >> >>> parts:
>> >> >>> a) divmod pass that transforms:
>> >> >>> t1 = a / b;
>> >> >>> t2 = a % b;
>> >> >>> to the following sequence:
>> >> >>> complex_tmp = DIVMOD (a, b);
>> >> >>> t1 = REALPART_EXPR(a);
>> >> >>> t2 = IMAGPART_EXPR(b);
>> >> >>>
>> >> >>> b) DIVMOD(a, b) is represented as an internal-fn and is expanded by
>> >> >>> expand_DIVMOD().
>> >> >>> I am not sure if I have done this correctly. I was somehow looking to
>> >> >>> reuse expand_divmod() but am not able to figure out how to do that
>> >> >>> (AFAIU expand_divmod() strictly returns either the quotient or
>> >> >>> remainder but never both which is what I want), so ended up with
>> >> >>> manually expanding to rtx.
>> >> >>>
>> >> >>> While going through the sincos pass in execute_cse_sincos_1, I didn't
>> >> >>> understand the following:
>> >> >>>  if (gimple_purge_dead_eh_edges (gimple_bb (stmt)))
>> >> >>>   cfg_changed = true;
>> >> >>> Um why is the call to gimple_purge_dead_eh_edges necessary here?
>> >> >>
>> >> >> The call replacement might no longer throw.
>> >> >>
>> >> >>> A silly question, what options to pass to gcc to print statistics ? I
>> >> >>> added statistics_counter_event to keep track of number of calls
>> >> >>> inserted/used but not sure how to print them :/
>> >> >>
>> >> >> -fdump-tree-XXX-stats or -fdump-statistics-stats
>> >> > Thanks, I can see it now -;)
>> >> >>
>> >> >>> I would be grateful for suggestions for improving the patch.
>> >> >>
>> >> >> First of all new functions need comments (expand_DIVMOD).
>> >> >>
>> >> >> Second - what's the reasoning for the pass placement seen?  I think
>> >> >> the transform is a lowering one, improving RTL expansion.  The
>> >> >> DIVMOD representation is harmful for GIMPLE optimizers.
>> >> >>
>> >> >> Third - I'd have integrated this with an existing pass - we have 
>> >> >> another
>> >> >> lowering / RTL expansion kind pass which is pass_optimize_widening_mul.
>> >> >> Please piggy-back on it.
>> >> >>
>> >> >> You seem to do the transform unconditionally even if the target has
>> >> >> instructions for division and modulus but no instruction for divmod
>> >> >> in which case you'll end up emitting a library call in the end instead
>> >> >> of a div and mod instruction.  I think the transform should be gated on
>> >> >> missing div/mod instructions or the availability of a divmod one.
>> >> >>
>> >> >> + if (is_gimple_assign (stmt)
>> >> >> + && TREE_CODE_CLASS (gimple_assign_rhs_code (stmt)) == 
>> >> >> tcc_binary)
>> >> >> +   {
>> >> >> + if (gimple_assign_rhs_code (stmt) == TRUNC_DIV_EXPR)
>> >> >> +   cfg_changed |= execute_divmod_1 (stmt);
>> >> >>
>> >> >> you can directly check gimple_assign_rhs_code.  I'd check for 
>> >> >> TRUNC_MOD_EXPR
>> >> >> which seems to be less common and thus should cut down compile-time.
>> >> >>
>> >> >> +  /* Case 2: When both are in top_bb */
>> >> >> +  else if (op1_def_in_bb && op2_def_in_bb)
>> >> >> +{
>> >> >> +  /* FIXME: better way to compare iterators?.  */
>> >> >> +  gimple_stmt_iterator gsi = get_later_stmt (top_bb,
>> >> >> def_stmt_op1, def_stmt_op2);
>> >> >>
>> >> >> You can't use get_later_stmt, it's a vectorizer speciality.  To do
>> >> >> this test efficiently
>> >> >> you need stmt UIDs computed.
>> >> >>
>> >> >> I miss a testcase (or two).
>> >> > I have tried to address your comments in the attached patch.
>> >> oops, unsigned uid_no = 0; should be outside the loop in
>> >> pass_optimize_widening_mul::execute.
>> >> Done in this version of the patch.
>> >>
>> >> Thanks,
>> >> Prathamesh
>> >> > Could you please review it for me ?
>> >
>> > For the testcases you need a new target check for divmod.
>> Sorry I didn't understand.
>> Should I add sth similar to /* {  dg-require-effective-target divmod } */ ?
>
> Yes.
>
>> >
>> >> > I have a few questions:
>> >> >
>> >> > a) Is the check for availability of divmod correct ?
>> >
>> > You simply want optab_handler (tab, mode) != CODE_FOR_nothing
>> >
>> > The libfunc is always available.
>> Um I am probably missing something, I thought libfuncs are initialized
>> by init_

GCC 6 Status Report (2015-11-09)

[Richard Biener]

Status
==

We've pushed back the switch to Stage 3 to the end of Saturday, Nov 14th.
This is to allow smooth draining of review queues.


Quality Data


Priority  #   Change from last report
---   ---
P14+   2
P2   84
P3  130+  10
P4   83-   5
P5   32
---   ---
Total P1-P3 218+  12
Total   333+   7


Previous Report
===

https://gcc.gnu.org/ml/gcc/2015-10/msg00113.html

Re: abi_tag questions

[Stephan Bergmann]

On 11/04/2015 12:48 PM, Jonathan Wakely wrote:

On 4 November 2015 at 14:37, Stephan Bergmann  wrote:

I have two questions regarding the abi_tag attribute (as documented at
):

[...]

2  "The argument can be a list of strings of arbitrary length."

Does that mean the list can be empty?


void f() __attribute__((__abi_tag__()));


fails with "error: wrong number of arguments specified for ‘__abi_tag__’
attribute" while


inline namespace n __attribute__((__abi_tag__())) {}


is accepted by recent trunk GCC (as well as older versions).


That seems like a bug.


Filed  "Reject empty 
abi_tag attribute on inline namespace" now.

Re: inline asm and multi-alternative constraints

[Jeff Law]

On 11/07/2015 12:50 AM, David Wohlferd wrote:


- Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable
for inline asm.  But both "#*" seem sketchy.
Right.  =+& are no-brainer yes, as are the constants 0-9.  % is probably 
OK as well.


#* are similar to !? in that they are inherently tied into the register 
class preferencing implementation and documenting them would be inadvisable.




- Under 'simple constraints', "mringX" all (more or less) make sense to
me.  But "oV<>sp" are not things I can envision using.
The various offsettables (oV), pre/post increment (<>), address (p) make 
senseI'm not sure about (s).




- The 'machine constraints' for i386 (the only machine I know) all seem
reasonable.  However for platforms that support autoincrement
(powerpc?), apparently using "m" needs more docs (per
https://gcc.gnu.org/ml/gcc/2008-03/msg01079.html).




Are these the things to which you are referring?  I've always assumed
the parts that seem obscure here were due to my i386-centric view of the
world.  Are some of them actually md-only?
A few may be md-only, but generally folks have found that getting access 
to the target's constraints to be useful in asms.  I was hesitant to 
document them initially because it made it much easier for someone to 
setup a situation where the compiler couldn't generate correct code. 
Those issues have (mostly) been fixed through the years.



Jeff