RE: vectorization cost macro TARGET_VECTORIZE_ADD_STMT_COST
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Ajit
Kumar Agarwal
Sent: Monday, August 17, 2015 4:03 PM
To: Richard Biener
Cc: Jeff Law; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli
Hunsigida; Nagaraju Mekala
Subject: RE: vectorization cost macro TARGET_VECTORIZE_ADD_STMT_COST
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Friday, August 14, 2015 9:59 PM
To: Ajit Kumar Agarwal
Cc: Jeff Law; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli
Hunsigida; Nagaraju Mekala
Subject: RE: vectorization cost macro TARGET_VECTORIZE_ADD_STMT_COST
On August 14, 2015 5:03:58 PM GMT+02:00, Ajit Kumar Agarwal
wrote:
>
>
>-Original Message-
>From: Richard Biener [mailto:richard.guent...@gmail.com]
>Sent: Monday, August 03, 2015 2:59 PM
>To: Ajit Kumar Agarwal
>Cc: Jeff Law; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta;
>Vidhumouli Hunsigida; Nagaraju Mekala
>Subject: Re: vectorization cost macro TARGET_VECTORIZE_ADD_STMT_COST
>
>On Sun, Aug 2, 2015 at 4:13 PM, Ajit Kumar Agarwal
> wrote:
>> All:
>>
>> The definition of the following macro that determine the statement
>cost that adds to vectorization cost.
>>
>> #define TARGET_VECTORIZE_ADD_STMT_COST.
>>
>> In the implementation of the above macro the following is done for
>many vectorization supported architectures like i386, ARM.
>>
>> if (where == vect_body && stmt_info && stmt_in_inner_loop_p
>(stmt_info))
>> count *= 50; /* FIXME. */
>>
>> I have the following questions.
>>
>> 1. Why the multiplication factor of 50 is choosen?
>
>>>It's a wild guess. See
>tree-vect-loop.c:vect_get_single_scalar_iteration_cost.
>
>> 2. The comment mentions that the inner loop relative to the loop
>being
>> vectorized is added more weight. If more weight is added to the inner
>
>> loop for the loop being vectorized, the chances of vectorizing the
>inner loop decreases. Why the inner loop cost is increased with
>relative to the loop being vectorized?
>
>>>In fact adding more weight to the inner loop increases the chance of
>vectorizing it (if vectorizing the inner loop is profitable).
>>>Both scalar and vector cost get biased by a factor of 50 (we assume
>50 iterations of the inner loop for one iteration of the outer loop),
>so a non-profitable >>vectorization in the outer loop can be offsetted
>by profitable inner loop vectorization.
>
>>>Yes, '50' can be improved if we actually know the iteration count of
>the inner loop or if we have profile-feedback.
>
>Instead of vector and scalar cost get biased by a factor of 50, Can the
>benefit of vectorization calculated as follows
>
>Benefit = scalar cost - vector cost/VF; Cost = 0; For ( I = 1; I < N;
>i++) {
>Cost = cost + (final_value - Initial value)/steps; }
>
>Benefit = Benefit * cost;
>
>Where
>N = No. of levels of the loop;
>Final_value = Final iteration count of the loop.
>Initial_value = Initial Iteration count of the loop.
>Steps = steps of the iteration for the loop.
>VF = vectorization factor.
>
>Thus increase in the Levels of the loops increases the benefit of
>vectorization. Also if the scalar cost is more than the vectorization
>cost then the Scalar cost - vector cost /VF increases with the same
>vectorization Factor thus increasing the benefit of vectorization.
>>Sure. But the number of iterations may only be available symbolically, thus
>>the cost be only useful for the dynamic check at runtime. A better static
estimate would also be useful.
>>Thanks. For the cases the loop bound can be known at the compile time,
>>through Value Range Analysis. Already GCC uses the value range
Information/Analysis To calculate the Loop bound. We can use the same loop
>>bound info to get the static estimate on the number of iterations.
>> Based on the above estimates, the above cost calculation as I have
>> mentioned can be used for Vectorization cost Analysis.
On top of the above, the vectorizer cannot vectorize the loops if the trip
count or iteration count is not known. In order to have the number
Of iterations for vectorizer cost calculation, it's always true the trip count
or iteration count is known. The summation of iteration count of all
the Loop levels where the iteration count is known, gives the static estimate
and included in the above vectorization cost. For the Loops where
iteration or trip count is not known, the vectorizer cannot vectorize and
iteration count of such cases can be neglected for the vectorization cost
calculation.
Only SLP or partial vectorization is possible where its considers the
isomorphic operations instead of vectorization based on trip or iteration
Count for the Loops.
Thanks & Regards
Ajit
Thanks & Regards
Ajit
Richard.
>Thanks & Regards
>Ajit
>
>Richard.
>
>
>> Thanks & Regards
>> Ajit
Re: ctype_members.cc Comparison Always True
On 19 August 2015 at 03:16, Martin Sebor wrote: > On 08/03/2015 12:35 PM, Joel Sherrill wrote: >> >> Hi >> >> Just noticed this building the head for arm-rtems4.11. Should >> the first comparison be eliminated and, maybe, a comment added? >> >> ctype_members.cc:216:14: warning: comparison of unsigned expression >= 0 >> is always true [-Wtype-limits] >> if (__wc >= 0 && __wc < 128 && _M_narrow_ok) >>^ >> ctype_members.cc: In member function 'virtual const wchar_t* >> std::ctype::do_narrow(const wchar_t*, const wchar_t*, char, >> char*) const': >> ctype_members.cc:230:14: warning: comparison of unsigned expression >= 0 >> is always true [-Wtype-limits] >> if (*__lo >= 0 && *__lo < 128) > > > Unconditionally removing the test alone wouldn't be right for targets > where wchar_t is a signed type. But casting the result to an unsigned > type with as much precision as wchar_t should make it possible to > remove it safely. Joel, please discuss this on the libstdc++ list instead so the relevant people notice it.
Compilation of object creation in C++
We are working on an analysis for identifying the class of an object flow
sensitively for
flow sensitive de-virtualization (i.e. replacing a virtual function call by a
call to the
function of a known class in the hierarchy). This is a regular ipa pass. It
find outs the
class of an object at point of creation and then propagates it.
In the examples we have seen so far, given a statement
B beta ("str");
It is is transformed by gcc-4.7.2 as shown below :
__comp_ctor (&beta, "str");
We use this information to identify the class.
However, for case in the source of GNU package gperf-3.0.4, a statement
Output_Enum style (" ");
is transformed by gcc 4.7.2 as
# DEBUG this => &style
# DEBUG indent => ""
# DEBUG D#62 => &style.D.4064
# DEBUG this => D#62
MEM[(struct Output_Constants *)&style]._vptr.Output_Constants = &MEM[(void
*)&_ZTV16Output_Constants + 16B];
style.D.4064._vptr.Output_Constants = &MEM[(void *)&_ZTV11Output_Enum +
16B];
style._indentation = "";
Why is this different? Why is __comp_ctor not invoked in each case?
The class hierarchy in gperf is as given below :
struct Output_Constants
{
virtual void output_start () = 0;
virtual void output_item (const char *name, int value) = 0;
virtual void output_end () = 0;
Output_Constants () {}
virtual ~Output_Constants () {}
};
struct Output_Enum : public Output_Constants
{
virtual void output_start ();
virtual void output_item (const char *name, int value);
virtual void output_end ();
Output_Enum (const char *indent)
: _indentation (indent) {}
virtual ~Output_Enum () {}
private:
const char *_indentation;
bool _pending_comma;
};
Thanks and regards,
Uday Khedker.
Re: Compilation of object creation in C++
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker wrote:
>
> We are working on an analysis for identifying the class of an object flow
> sensitively for
> flow sensitive de-virtualization (i.e. replacing a virtual function call by
> a call to the
> function of a known class in the hierarchy). This is a regular ipa pass. It
> find outs the
> class of an object at point of creation and then propagates it.
Most of this is already in GCC 5 and above. Including the IPA pass.
Have you looked into that pass yet?
>
> In the examples we have seen so far, given a statement
>
> B beta ("str");
>
> It is is transformed by gcc-4.7.2 as shown below :
>
> __comp_ctor (&beta, "str");
>
> We use this information to identify the class.
>
> However, for case in the source of GNU package gperf-3.0.4, a statement
>
> Output_Enum style (" ");
>
> is transformed by gcc 4.7.2 as
>
> # DEBUG this => &style
> # DEBUG indent => ""
> # DEBUG D#62 => &style.D.4064
> # DEBUG this => D#62
> MEM[(struct Output_Constants *)&style]._vptr.Output_Constants =
> &MEM[(void *)&_ZTV16Output_Constants + 16B];
> style.D.4064._vptr.Output_Constants = &MEM[(void *)&_ZTV11Output_Enum
> + 16B];
> style._indentation = "";
>
> Why is this different? Why is __comp_ctor not invoked in each case?
This looks like the function has been inlined as it is short.
Thanks,
Andrew Pinski
>
> The class hierarchy in gperf is as given below :
>
> struct Output_Constants
> {
> virtual void output_start () = 0;
> virtual void output_item (const char *name, int value) = 0;
> virtual void output_end () = 0;
> Output_Constants () {}
> virtual ~Output_Constants () {}
> };
>
> struct Output_Enum : public Output_Constants
> {
> virtual void output_start ();
> virtual void output_item (const char *name, int value);
> virtual void output_end ();
> Output_Enum (const char *indent)
> : _indentation (indent) {}
> virtual ~Output_Enum () {}
> private:
> const char *_indentation;
> bool _pending_comma;
> };
>
> Thanks and regards,
>
> Uday Khedker.
>
>
[PATCH][ARM]Tighten the conditions for arm_movw, arm_movt
Hi all,
This simple patch will tighten the conditions when matching movw and
arm_movt rtx pattern.
Those two patterns will generate the following assembly:
movw w1, #:lower16: dummy + addend
movt w1, #:upper16: dummy + addend
The addend here is optional. However, it should be an 16-bit signed
value with in the range -32768 <= A <= 32768.
By impose this restriction explicitly, it will prevent LRA/reload code
from generation invalid high/lo_sum code for arm target.
In process_address_1(), if the address is not legitimate, it will try to
generate high/lo_sum pair to put the address into register. It will
check if the target support those newly generated reload instructions.
By define those two patterns, arm will reject them if conditions is not
meet.
Otherwise, it might generate movw/movt instructions with addend larger
than 32768, this will cause a GAS error. GAS will produce '''offset out
of range'' error message when the addend for MOVW/MOVT REL relocation is
too large.
arm-none-eabi regression tests Okay, Okay to commit to the trunk and
backport to 5.0?
Regards,
Renlin
gcc/ChangeLog:
2015-08-19 Renlin Li
* config/arm/arm-protos.h (arm_valid_symbolic_address_p): Declare.
* config/arm/arm.c (arm_valid_symbolic_address_p): Define.
* config/arm/arm.md (arm_movt): Use arm_valid_symbolic_address_p.
* config/arm/constraints.md ("j"): Add check for high code.
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 16eb854..ebaf746 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -312,6 +312,7 @@ extern int vfp3_const_double_for_bits (rtx);
extern void arm_emit_coreregs_64bit_shift (enum rtx_code, rtx, rtx, rtx, rtx,
rtx);
+extern bool arm_valid_symbolic_address_p (rtx);
extern bool arm_validize_comparison (rtx *, rtx *, rtx *);
#endif /* RTX_CODE */
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index cf60313..860c784 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -28811,6 +28811,35 @@ arm_emit_coreregs_64bit_shift (enum rtx_code code, rtx out, rtx in,
#undef BRANCH
}
+/* Returns true if the pattern is a valid symbolic address, which is either a
+ symbol_ref or a symbol_ref + offset. */
+bool
+arm_valid_symbolic_address_p (rtx addr)
+{
+ rtx xop0, xop1 = NULL_RTX;
+ rtx tmp = addr;
+
+ if (GET_CODE (tmp) == SYMBOL_REF || GET_CODE (tmp) == LABEL_REF)
+return true;
+
+ /* (const (plus: symbol_ref const_int)) */
+ if (GET_CODE (addr) == CONST)
+tmp = XEXP (addr, 0);
+
+ xop0 = XEXP (tmp, 0);
+ xop1 = XEXP (tmp, 1);
+ if (GET_CODE (tmp) == PLUS && GET_CODE (xop0) == SYMBOL_REF
+ && CONST_INT_P (xop1))
+{
+ HOST_WIDE_INT offset = INTVAL (xop1);
+ if (offset < -0x8000 || offset > 0x7fff)
+ return false;
+ else
+ return true;
+}
+
+ return false;
+}
/* Returns true if a valid comparison operation and makes
the operands in a form that is valid. */
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index f63fc39..7ac4f34 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -5662,7 +5662,7 @@
[(set (match_operand:SI 0 "nonimmediate_operand" "=r")
(lo_sum:SI (match_operand:SI 1 "nonimmediate_operand" "0")
(match_operand:SI 2 "general_operand" "i")))]
- "arm_arch_thumb2"
+ "arm_arch_thumb2 && arm_valid_symbolic_address_p (operands[2])"
"movt%?\t%0, #:upper16:%c2"
[(set_attr "predicable" "yes")
(set_attr "predicable_short_it" "no")
diff --git a/gcc/config/arm/constraints.md b/gcc/config/arm/constraints.md
index 42935a4..f9e11e0 100644
--- a/gcc/config/arm/constraints.md
+++ b/gcc/config/arm/constraints.md
@@ -67,7 +67,8 @@
(define_constraint "j"
"A constant suitable for a MOVW instruction. (ARM/Thumb-2)"
(and (match_test "TARGET_32BIT && arm_arch_thumb2")
- (ior (match_code "high")
+ (ior (and (match_code "high")
+ (match_test "arm_valid_symbolic_address_p (XEXP (op, 0))"))
(and (match_code "const_int")
(match_test "(ival & 0x) == 0")
Re: Compilation of object creation in C++
Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM: On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker wrote: We are working on an analysis for identifying the class of an object flow sensitively for flow sensitive de-virtualization (i.e. replacing a virtual function call by a call to the function of a known class in the hierarchy). This is a regular ipa pass. It find outs the class of an object at point of creation and then propagates it. Most of this is already in GCC 5 and above. Including the IPA pass. Have you looked into that pass yet? From what I have read, it involves flow insensitive analysis whereas we are looking at flow sensitive analysis. Uday.
Re: Compilation of object creation in C++
On Wed, Aug 19, 2015 at 2:10 PM, Uday P. Khedker wrote: > > > Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM: >> >> On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker >> wrote: >>> >>> We are working on an analysis for identifying the class of an object flow >>> sensitively for >>> flow sensitive de-virtualization (i.e. replacing a virtual function call >>> by >>> a call to the >>> function of a known class in the hierarchy). This is a regular ipa pass. >>> It >>> find outs the >>> class of an object at point of creation and then propagates it. >> >> Most of this is already in GCC 5 and above. Including the IPA pass. >> Have you looked into that pass yet? > > > From what I have read, it involves flow insensitive analysis whereas we are > looking at flow sensitive analysis. It also performs flow-sensitive analysis, exactly like you suggest by looking for constructor calls or patterns that involve setting the vtable pointer exposed through inlining. Richard. > Uday.
Re: Adding static-PIE support to binutils
If a new option is added, of course it needs documenting in the ld manual (ld.texinfo). -- Joseph S. Myers jos...@codesourcery.com
Adding an IPA pass question (pass names)
I am trying to create a new IPA pass to scan the routines being compiled
by GCC and I thought I would put it in after the last IPA pass (comdats)
so I tried to register it with:
opt_pass *p = make_pass_ipa_frame_header_opt (g);
static struct register_pass_info f =
{p, "comdats", 1, PASS_POS_INSERT_AFTER };
register_pass (&f);
But when I build GCC I get:
/scratch/sellcey/repos/header2/src/gcc/libgcc/libgcc2.c:1:0: fatal error: pass
'comdats' not found but is referenced by new pass 'frame-header-opt'
Does anyone know why this is the case? "comdats" is what is used for
the name of pass_ipa_comdats in ipa-comdats.c.
Steve Ellcey
sell...@imgtec.com
Re: Adding an IPA pass question (pass names)
On Wed, 2015-08-19 at 10:27 -0700, Steve Ellcey wrote:
> I am trying to create a new IPA pass to scan the routines being compiled
> by GCC and I thought I would put it in after the last IPA pass (comdats)
> so I tried to register it with:
>
> opt_pass *p = make_pass_ipa_frame_header_opt (g);
> static struct register_pass_info f =
> {p, "comdats", 1, PASS_POS_INSERT_AFTER };
> register_pass (&f);
>
> But when I build GCC I get:
>
> /scratch/sellcey/repos/header2/src/gcc/libgcc/libgcc2.c:1:0: fatal error:
> pass 'comdats' not found but is referenced by new pass 'frame-header-opt'
>
> Does anyone know why this is the case? "comdats" is what is used for
> the name of pass_ipa_comdats in ipa-comdats.c.
Is your pass of the correct type? (presumably IPA_PASS). I've run into
this a few times with custom passes (which seems to be a "gotcha");
position_pass can fail here:
/* Check if the current pass is of the same type as the new pass and
matches the name and the instance number of the reference pass. */
if (pass->type == new_pass_info->pass->type
Hope this is helpful
Dave
Re: Adding an IPA pass question (pass names)
On Wed, 2015-08-19 at 13:40 -0400, David Malcolm wrote: > Is your pass of the correct type? (presumably IPA_PASS). I've run into > this a few times with custom passes (which seems to be a "gotcha"); > position_pass can fail here: > > /* Check if the current pass is of the same type as the new pass and > matches the name and the instance number of the reference pass. */ > if (pass->type == new_pass_info->pass->type > > > Hope this is helpful > Dave That seems to have been the problem. I made my pass SIMPLE_IPA_PASS and the comdats pass is just IPA_PASS. I changed mine to IPA_PASS and it now registers the pass. Steve Ellcey sell...@imgtec.com
Question about "instruction merge" pass when optimizing for size
When compiling ARM/thumb with -Os for size, I've seen some cases where GCC generates unnecessary move instructions. It seems sometimes that there are some possibility to improve the use from 2-operand into 3-operand instructions. Some patterns I see is: Generated code Case 1: mov Ry, Rx ... add Ry,Ry,Rz mov Rx,Ry --> can be transformed to add Rx, Rz mov Ry, Rx Generated code Case 2: mov Ry, Rx add Ry, Ry, Rx -> can be transformed to add Ry,Ry,Ry - Generated code Case 3: mov Ry,Rx add Rz,Ry,Rx ... mov Rx,Ry -> can be transformed to add Rz,Rx,Rx mov Ry,Rx -- I'm sure there are alot of more similar patterns, I guess 'add' could be 'sub' or other instructions. It seems like the optimizers sometimes prefer the additional move, maybe for performance its equal due to other instruction stall etc, but when optimizing for size, its quite straight forward that you can gain bytes on these transformations, if possible, and should be preferred. The thing I was thinking of if it was possible to add a more generic GCC pass that could check for such "transformations", like an 'merge_multi_operator_insn' pass, that could do these transformations for any target, not only 2-op to 3-op transforms. Or maybe this is a peephole2 type of pass. The pass could be run maybe just if optimizing for size, where the cost is obvious (bytes generated). The pass could maybe be executed after reload when all hard registers are set, but before scheduling passes, like sched2. Proposed inbetween "pass_cprop_hardreg" and "pass_fast_rtl_dce". I'm new to these topics, so maybe I'm all wrong, but please comment my ideas if you have the time =) Thanks and Kind Regards, Fredrik
Re: Question about "instruction merge" pass when optimizing for size
I've seen this on other targets too, sometimes so bad I write a quick target-specific "stupid move optimizer" pass to clean it up. A generic pass would be much harder, but very useful.
RE: Question about "instruction merge" pass when optimizing for size
DJ Delorie writes: > I've seen this on other targets too, sometimes so bad I write a quick > target-specific "stupid move optimizer" pass to clean it up. > > A generic pass would be much harder, but very useful. Robert (on cc) is currently attempting some improvements to the regrename pass to try and propagate registers back from the destination of a move in order that the move becomes a no-op. This is for a few cases we have seen for MIPS. If successful that may clean up a small number of such problems for all targets. Thanks, Matthew
Re: Question about "instruction merge" pass when optimizing for size
On 08/19/2015 02:38 PM, DJ Delorie wrote: I've seen this on other targets too, sometimes so bad I write a quick target-specific "stupid move optimizer" pass to clean it up. A generic pass would be much harder, but very useful. More important is to determine *why* we're getting these patterns. In the IRA/LRA world, they should be a lot less common. Jeff
Re: Using the asm suffix
(Resending due to email glitch)
Thanks again for your comments.
On 8/18/2015 2:23 AM, Segher Boessenkool wrote:
On Mon, Aug 17, 2015 at 09:55:48PM -0700, David Wohlferd wrote:
On systems where an underscore is normally prepended to the name
of a C
-function or variable, this feature allows you to define names for the
+variable, this feature allows you to define names for the
linker that do not start with an underscore.
Why remove this?
This doc section (Controlling Names Used in Assembler Code) describes
how the asm suffix affects both data and functions. However, it jumbles
the two descriptions together.
Probably because they are the same thing...
My intent here is to break this clearly into two @subsubheadings:
'Assembler names for data' and 'Assembler names for functions'. Since
data is the first section, I removed the word 'function' here.
I missed that, sorry. Or, did you forget to add the same text to the
"function" description?
This patch would be much easier to review if you did one change per
patch.
I'm not sure what 'one change' might mean in this context. This topic
is all a single texi node (ie it all ends up on a single html page).
This page isn't that big. Would looking at the output help clarify this:
Current: https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html
Proposed: http://limegreensocks.com/gcc/Asm-Labels.html
It does not make sense to use this feature with a non-static local
variable since such variables do not have assembler names. If
you are
trying to put the variable in a particular register, see
@ref{Explicit
-Reg Vars}. GCC presently accepts such code with a warning, but will
-probably be changed to issue an error, rather than a warning, in the
-future.
+Reg Vars}.
And this?
Vague statements about possible changes that may or not ever be written
are not helpful in docs. In this case the statement is particularly
unhelpful since even the warning appears to be gone.
I don't agree it is a vague statement about possible future changes; it
is more like a statement of intent.
Saying this will "probably" change at some (unspecified) time "in the
future" seems the very definition of vague. Especially when you
consider that the docs have been threatening this change for over 15
years now.
It tells the reader "don't write code like this".
If this is intended just for emphasis, how about replacing the existing
text ("It does not make sense to use this feature with a non-static
local variable since such variables do not have assembler names.") with
"Do not use this feature with a non-static local variable." or maybe "It
is not supported to use this feature with a non-static local variable
since such variables do not have assembler names."
Saying "It does not make sense" to do something doesn't mean the same
thing (to me) as "Do not do this" or "It is not supported to..."
And the warning is still there ("ignoring asm-specifier for non-static
local variable").
Huh. I was unable to get gcc to produce this warning. Is there a trick?
int main()
{
int a asm("asdf");
a = 13;
return a;
}
I have tried 4.9.2 and 5, with -O2 and -O0, and I'm getting no warning
(or error) messages.
-Also, you must not use a
-register name; that would produce completely invalid assembler
code. GCC
-does not as yet have the ability to store static variables in
registers.
-Perhaps that will be added.
And why remove these?
Again with the vague statements about possible future changes. Also,
whether or not static variables can be stored in registers has nothing
to do with Asm Labels. If this is still true, it belongs in Explicit
Reg Vars.
The first part ("must not use a register name") is an important warning.
Clarifying this is a good idea. Although limiting it to only saying
"don't use register names" seems a little, well, limiting. Who knows
what kind of offsets or asm qualifiers they might try to cram in here?
How about:
"Only label names valid for your assembler are permitted within the asm."
This would go right after the warning about conflicts.
The second part (about statics) might well be better moved, but it should
not be _re_moved just like that! And it is still true (gives an error,
"multiple storage classes").
I have already started work on the changes I think are needed for
Explicit Reg Vars (the last section of gcc docs I'm planning on doing).
But I want to finish the (relatively easy) Asm Labels stuff first.
Should I put this change in there? Or would someone just tell me all
the Asm Labels stuff should go in its own patch?
Also, I'm not seeing the multiple storage classes message either:
int main()
{
static int a asm("asdf");
a = 5;
return a;
}
dw
Re: Using the asm suffix
On Wed, Aug 19, 2015 at 02:08:16PM -0700, David Wohlferd wrote:
> >>My intent here is to break this clearly into two @subsubheadings:
> >>'Assembler names for data' and 'Assembler names for functions'. Since
> >>data is the first section, I removed the word 'function' here.
> >I missed that, sorry. Or, did you forget to add the same text to the
> >"function" description?
> >
> >This patch would be much easier to review if you did one change per
> >patch.
>
> I'm not sure what 'one change' might mean in this context.
You're moving various things around. You are removing some, too.
It is hard (harder than necessary) to figure out which is which.
> It does not make sense to use this feature with a non-static local
> variable since such variables do not have assembler names. If
> you are
> trying to put the variable in a particular register, see
> @ref{Explicit
> -Reg Vars}. GCC presently accepts such code with a warning, but will
> -probably be changed to issue an error, rather than a warning, in the
> -future.
> +Reg Vars}.
> >>>And this?
> >>Vague statements about possible changes that may or not ever be written
> >>are not helpful in docs. In this case the statement is particularly
> >>unhelpful since even the warning appears to be gone.
> >I don't agree it is a vague statement about possible future changes; it
> >is more like a statement of intent.
>
> Saying this will "probably" change at some (unspecified) time "in the
> future" seems the very definition of vague. Especially when you
> consider that the docs have been threatening this change for over 15
> years now.
Certainly. But just deleting it is losing information.
> >It tells the reader "don't write code like this".
>
> If this is intended just for emphasis,
That is how I read it, anyway.
> how about replacing the existing
> text ("It does not make sense to use this feature with a non-static
> local variable since such variables do not have assembler names.") with
> "Do not use this feature with a non-static local variable." or maybe "It
> is not supported to use this feature with a non-static local variable
> since such variables do not have assembler names."
"You cannot use this feature ..." etc.? Keep the part about not having
assembler names, it is useful.
> Saying "It does not make sense" to do something doesn't mean the same
> thing (to me) as "Do not do this" or "It is not supported to..."
It is not the style of the manual, for sure.
> >And the warning is still there ("ignoring asm-specifier for non-static
> >local variable").
>
> Huh. I was unable to get gcc to produce this warning. Is there a trick?
See below...
> -Also, you must not use a
> -register name; that would produce completely invalid assembler
> code. GCC
> -does not as yet have the ability to store static variables in
> registers.
> -Perhaps that will be added.
> >>>And why remove these?
> >>Again with the vague statements about possible future changes. Also,
> >>whether or not static variables can be stored in registers has nothing
> >>to do with Asm Labels. If this is still true, it belongs in Explicit
> >>Reg Vars.
> >The first part ("must not use a register name") is an important warning.
>
> Clarifying this is a good idea. Although limiting it to only saying
> "don't use register names" seems a little, well, limiting. Who knows
> what kind of offsets or asm qualifiers they might try to cram in here?
Register names is the common case to hurt you... "r0" etc. ;-)
> How about:
>
> "Only label names valid for your assembler are permitted within the asm."
The assembler calls it "symbol names" (labels end in a colon). But it
won't help: e.g. "r0" is a perfectly fine name for the assembler, too!
It should say something like "if the string you put here is seen as
something else than a symbol name by the assembler, anywhere the compiler
puts it, you're on your own", but that is pretty vague as well.
> >The second part (about statics) might well be better moved, but it should
> >not be _re_moved just like that! And it is still true (gives an error,
> >"multiple storage classes").
>
> I have already started work on the changes I think are needed for
> Explicit Reg Vars (the last section of gcc docs I'm planning on doing).
> But I want to finish the (relatively easy) Asm Labels stuff first.
> Should I put this change in there? Or would someone just tell me all
> the Asm Labels stuff should go in its own patch?
>
> Also, I'm not seeing the multiple storage classes message either:
>
> int main()
> {
>static int a asm("asdf");
>a = 5;
>return a;
> }
You forgot to make it "register", so it is not a register variable.
Try this, for both the warning and error (tested with 4.7, 4.9, 5, 6):
--- 8< ---
int f(void)
{
static register int lol asm("r20");
int foo asm("myfoo") = 42;
return foo + lol;
}
--- 8< ---
fooasm.c: In
RE: Question about "instruction merge" pass when optimizing for size
(It appears I accidentally dropped the mailing list) Hi, > On 08/19/2015 02:38 PM, DJ Delorie wrote: > > I've seen this on other targets too, sometimes so bad I write a quick > > target-specific "stupid move optimizer" pass to clean it up. > > > > A generic pass would be much harder, but very useful. > More important is to determine *why* we're getting these patterns. In > the IRA/LRA world, they should be a lot less common. > > Jeff AFAIU LRA is less likely to remove the moves if it didn't introduce itself. In one specific MIPS case for 64-bit, the moves are inserted for the sign-extension but IRA spills some of the allocnos and assigns different hard register for the output operand in the move as the initial register is call clobbered and the move proves to be difficult to remove later. I found tricky to remove the move in the register allocator and my current approach is to exploit the regname pass to link some of the chains and rename the input registers to turn the move into a no-op as Matthew already mentioned. I agree that it would be ideal to do the right thing in IRA/LRA but the heuristic is sensitive to changes. Regards, Robert
gcc-4.9-20150819 is now available
Snapshot gcc-4.9-20150819 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150819/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 227017 You'll find: gcc-4.9-20150819.tar.bz2 Complete GCC MD5=660b30577c0f79d78fe6ffc269c593f1 SHA1=f80756b25aa177ef28cbf2a0cd0c37ebd71abb13 Diffs from 4.9-20150812 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Re: Using the asm suffix
[snip]
how about replacing the existing
text ("It does not make sense to use this feature with a non-static
local variable since such variables do not have assembler names.") with
"Do not use this feature with a non-static local variable." or maybe "It
is not supported to use this feature with a non-static local variable
since such variables do not have assembler names."
"You cannot use this feature ..." etc.? Keep the part about not having
assembler names, it is useful.
Due to the quirks of the English language, I'm not sure 'cannot' is the
right word here. More correct would be 'cannot reliably' but I don't
want to be that wishy-washy.
And I'm a little iffy about the 'since such variables do not have
assembler names,' as it seemed a bit bold to make assertions about the
implementation details for all assemblers (past, present and future) for
all platforms. But you are right, it does convey a bit of the 'why' for
this limitation, so keeping it is a good idea. How about:
"gcc does not support using this feature with a non-static local
variable since typically such variables do not have assembler names."
BTW, the trick for getting the "ignoring asm-specifier for non-static
local variable" message was renaming my file from sta5.cpp to sta5.c.
Seems like this should apply to both, but whatever.
The first part ("must not use a register name") is an important warning.
Clarifying this is a good idea. Although limiting it to only saying
"don't use register names" seems a little, well, limiting. Who knows
what kind of offsets or asm qualifiers they might try to cram in here?
Register names is the common case to hurt you... "r0" etc. ;-)
But as we have seen (%gs:4), people are willing to try other things.
And rather than try to list all the things that don't work (register,
registers with offsets, etc), I'm hoping we can find a way to specify
the one thing that is supported.
How about:
"Only label names valid for your assembler are permitted within the asm."
The assembler calls it "symbol names" (labels end in a colon). But it
won't help: e.g. "r0" is a perfectly fine name for the assembler, too!
It should say something like "if the string you put here is seen as
something else than a symbol name by the assembler, anywhere the compiler
puts it, you're on your own", but that is pretty vague as well.
Ok, how about "Only symbol names that define labels are permitted within
the asm."
A bit awkward, but I believe it conveys the intent.
You forgot to make it "register", so it is not a register variable.
Ahh, true. I suppose we could say something about don't use 'register'
with 'asm labels', but it doesn't seem worth the effort.
dw
