RE: Could not identify that register is clobbered already
> From: Georg-Johann Lay [mailto:a...@gjlay.de] > S, Pitchumani schrieb: > > > > From: Georg-Johann Lay > >> S, Pitchumani wrote: > >> ... > >> Trying to introduce hard_frame_pointer was dropped because the code > >> turned out to have unusable had efficiency. I don't find the patch, > >> AFAIR it is Denis' work, thus CCing him. > >> > >> But without a test case nobody can tell... > > > > This behavior is observed for dejagnu test case "gcc.dg/var-expand2.c" > when > > gcc-4.7.2 is used. > > > > Options used: -O2 -funroll-loops -ffast-math -mmcu=atxmega128b1 > > The generated code is wrong. You can file a PR. Thanks. PR 56442 is filed for this. Thanks. Regards, Pitchumani
Re: Question on multiplied address cost computation in ivopt
On Fri, Feb 22, 2013 at 9:42 AM, Bin.Cheng wrote:
> Hi,
> Function get_address_cost in ivopt computes multiplied address cost
> with below code:
>
> First:
> rat = 1;
> for (i = 2; i <= MAX_RATIO; i++)
> if (multiplier_allowed_in_address_p (i, mem_mode, as))
> {
> rat = i;
> break;
> }
>
> Then:
> if (rat_p)
> addr = gen_rtx_fmt_ee (MULT, address_mode, addr,
>gen_int_mode (rat, address_mode));
>
> What's the purpose of first iteration? It just finds the first allowed
> ratio in address, causing the generated ADDR always has the minimal
> allowed ratio. Is it right?
Looks like so.
> For target doesn't support multiplied address, the generated ADDR is:
> (MULT reg, 1). The cost generally is equal to address with pure
> register. What's the meaning of this cost?
Look at its uses.
Richard.
> Thanks very much.
>
>
> --
> Best Regards.
Re: REG_UNUSED notes for CLOBBERs?
> It seems to me that a REG_UNUSED note on a CLOBBER is unnecessary, and > it also goes against the documented purpose of a REG_UNUSED note in > reg-notes.def: > > /* Identifies a register set in this insn and never used. */ > REG_NOTE (UNUSED) > > After all, a CLOBBER is not a register set, so I think a patch like > the one below is necessary. > > Thoughts? This looks more like a small oversight in the DF implementation than a real design decision, so I'd go ahead with your patch. -- Eric Botcazou
Re: GCC 4.8 and -Og
On Mon, Feb 25, 2013 at 6:20 AM, Chung-Ju Wu wrote: > 2013/2/25 Jeffrey Walton : >> Hi All, >> >> I read the relase notes on GCC 4.8 >> (http://gcc.gnu.org/gcc-4.8/changes.html) and -Og caught my eye (the >> bulleted item is below). > [deleted] >> >> What "n" does -Og correspond to for -O and -g (i.e., -O1, -O2; -g2, -g3)? -Og does not correspond to any other -O plus -g level. -Og does not enable debug info creation either (eh, I _knew_ that was going to be confusing ...). To enable debug information generation you need to use -Og -g. -Og optimizes way less than -O1 but more than -O0 (it for example does inlining of C++ abstraction, constant propagation, full redundancy elimination and dead code elimination). > [deleted] >> Is -Og -g3 a valid combination to get the benefits of -Og with maximum >> symbol support? Is it even needed? Yes, it's valid and it's even needed. >> Jeff >> > > To my understanding, '-Og' selects optimization level 1 > so that you can have fast compilation and a superior debugging experience. As said above this is not exactly true. The __OPTIMIZE__ preprocessor macro will be 1 though. > You still need to use -g (or -g3, which is the option you normally use.) > to guide GCC output debug information. > > Refer to following link for some -Og implementation detail: > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00616.html Also note that evaluation whether 1), 2) or 3) hold true has not been done, bugreports are welcome. Thanks, Richard. > > Best regards, > jasonwu
Re: GCC 4.8 and -Og
On Mon, Feb 25, 2013 at 4:51 AM, Richard Biener wrote: > On Mon, Feb 25, 2013 at 6:20 AM, Chung-Ju Wu wrote: >> 2013/2/25 Jeffrey Walton : >>> Hi All, >>> >>> I read the relase notes on GCC 4.8 >>> (http://gcc.gnu.org/gcc-4.8/changes.html) and -Og caught my eye (the >>> bulleted item is below). >> [deleted] >>> >>> What "n" does -Og correspond to for -O and -g (i.e., -O1, -O2; -g2, -g3)? > > -Og does not correspond to any other -O plus -g level. -Og does not enable > debug info creation either (eh, I _knew_ that was going to be confusing ...). > To enable debug information generation you need to use -Og -g. > > -Og optimizes way less than -O1 but more than -O0 (it for example does > inlining of C++ abstraction, constant propagation, full redundancy elimination > and dead code elimination). > >> [deleted] >>> Is -Og -g3 a valid combination to get the benefits of -Og with maximum >>> symbol support? Is it even needed? > > Yes, it's valid and it's even needed. > >> >> To my understanding, '-Og' selects optimization level 1 >> so that you can have fast compilation and a superior debugging experience. > > As said above this is not exactly true. The __OPTIMIZE__ preprocessor > macro will be 1 though. > >> You still need to use -g (or -g3, which is the option you normally use.) >> to guide GCC output debug information. >> >> Refer to following link for some -Og implementation detail: >> http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00616.html > > Also note that evaluation whether 1), 2) or 3) hold true has not been > done, bugreports are welcome. Thanks Richard and Jason. Don't worry about possible confusion (-Og needs -gN). Document it at http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options, and folks should be able to find it. (That's the first place I looked). Address Sanitizer looks very interesting also (-fsanitize=address). It's listed at http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html, but there's no topic when following the link to http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options. Jeff
Re: Question on multiplied address cost computation in ivopt
On Mon, Feb 25, 2013 at 5:39 PM, Richard Biener
wrote:
> On Fri, Feb 22, 2013 at 9:42 AM, Bin.Cheng wrote:
>> Hi,
>> Function get_address_cost in ivopt computes multiplied address cost
>> with below code:
>>
>> First:
>> rat = 1;
>> for (i = 2; i <= MAX_RATIO; i++)
>> if (multiplier_allowed_in_address_p (i, mem_mode, as))
>> {
>> rat = i;
>> break;
>> }
>>
>> Then:
>> if (rat_p)
>> addr = gen_rtx_fmt_ee (MULT, address_mode, addr,
>>gen_int_mode (rat, address_mode));
>>
>> What's the purpose of first iteration? It just finds the first allowed
>> ratio in address, causing the generated ADDR always has the minimal
>> allowed ratio. Is it right?
>
> Looks like so.
>
>> For target doesn't support multiplied address, the generated ADDR is:
>> (MULT reg, 1). The cost generally is equal to address with pure
>> register. What's the meaning of this cost?
>
> Look at its uses.
Thanks, now I understand that it calculates representative cost for
multiplied address, then uses it later. Doesn't matter which ratio is
used generally.
Another question about multiplied address is in function
multiplier_allowed_in_address_p, it constructs rtx like "(MULT reg1,
ratio)" and let backend determine whether multiplied address is
allowed. I suspect the code is implemented/tested on x86, since
machine like ARM only supports multiplied address with non-null base
register, like "base + reg * index". The code causes multiplied
address disabled totally for ARM machine.
Any comments?
Thanks
--
Best Regards.
Re: GCC 4.8 and -Og
Jeffrey Walton wrote: On Mon, Feb 25, 2013 at 4:51 AM, Richard Biener wrote: On Mon, Feb 25, 2013 at 6:20 AM, Chung-Ju Wu wrote: Don't worry about possible confusion (-Og needs -gN). Document it at http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options, and folks should be able to find it. (That's the first place I looked). I leave this to others. Address Sanitizer looks very interesting also (-fsanitize=address). It's listed at http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html, but there's no topic when following the link to http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options. That's a section-ordering bug. The flag is (wrongly) documented under optimization options, i.e. in the next section: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html That's now fixed. Tobias
Re: Question on multiplied address cost computation in ivopt
On Mon, Feb 25, 2013 at 11:13 AM, Bin.Cheng wrote:
> On Mon, Feb 25, 2013 at 5:39 PM, Richard Biener
> wrote:
>> On Fri, Feb 22, 2013 at 9:42 AM, Bin.Cheng wrote:
>>> Hi,
>>> Function get_address_cost in ivopt computes multiplied address cost
>>> with below code:
>>>
>>> First:
>>> rat = 1;
>>> for (i = 2; i <= MAX_RATIO; i++)
>>> if (multiplier_allowed_in_address_p (i, mem_mode, as))
>>> {
>>> rat = i;
>>> break;
>>> }
>>>
>>> Then:
>>> if (rat_p)
>>> addr = gen_rtx_fmt_ee (MULT, address_mode, addr,
>>>gen_int_mode (rat, address_mode));
>>>
>>> What's the purpose of first iteration? It just finds the first allowed
>>> ratio in address, causing the generated ADDR always has the minimal
>>> allowed ratio. Is it right?
>>
>> Looks like so.
>>
>>> For target doesn't support multiplied address, the generated ADDR is:
>>> (MULT reg, 1). The cost generally is equal to address with pure
>>> register. What's the meaning of this cost?
>>
>> Look at its uses.
>
> Thanks, now I understand that it calculates representative cost for
> multiplied address, then uses it later. Doesn't matter which ratio is
> used generally.
>
> Another question about multiplied address is in function
> multiplier_allowed_in_address_p, it constructs rtx like "(MULT reg1,
> ratio)" and let backend determine whether multiplied address is
> allowed. I suspect the code is implemented/tested on x86, since
> machine like ARM only supports multiplied address with non-null base
> register, like "base + reg * index". The code causes multiplied
> address disabled totally for ARM machine.
> Any comments?
Well - enhance it. Best without the need to construct an RTX in the
first place ;)
Richard.
> Thanks
>
>
> --
> Best Regards.
dummy DejaGnu board files
I've been using a couple of DejaGnu board files to test multilibs for
which I don't have any way to execute tests, and for which I can't even
link because I don't have compatible libraries. I'd like to share but
don't know where to put them; any suggestions?
Janis
Index: dummy-link.exp
===
--- dummy-link.exp (revision 0)
+++ dummy-link.exp (revision 0)
@@ -0,0 +1,63 @@
+
+#
+# File: dummy-link.exp
+# Author: Janis Johnson
+# Date: 2013-02-25
+#
+# Contents:
+#
+# DejaGNU board configuration file for a null target board and no
+# libraries.
+#
+
+
+load_generic_config "sim"
+set_board_info hostname "dummy-link"
+set board_info(localhost,isremote) 0
+process_multilib_options ""
+
+# Override target_compile to downgrade link to compile and skip compile
+# of multiple source files.
+if { [info procs saved_target_compile] == [list] } {
+rename target_compile saved_target_compile
+proc target_compile { source destfile type options } {
+ if { $type == "executable" } {
+ set path_string "gcc/testsuite"
+ set i1 [string first $path_string $source]
+ set i2 [string last $path_string $source]
+ if { [regexp $path_string $options]
+|| $i1 != $i2 } {
+ global compiler_conditional_xfail_data
+ set compiler_conditional_xfail_data [list]
+ lappend compiler_conditional_xfail_data "unknown-*-*"
+ lappend compiler_conditional_xfail_data "*"
+ return "skip compile of multiple source files and expect it to
fail"
+ }
+ set type "object"
+ regsub ".exe" $destfile ".o" destfile
+ send_user "target_compile: change executable to object\n"
+ }
+ return [saved_target_compile $source $destfile $type $options]
+}
+}
+
+# ${tool}_check_compile reports the status of the compile step, and the
+# return value determines whether an execution step is run or is
+# reported as unresolved. Let the real one report whether the compile
+# passed or failed, but always treat the execution as unresolved.
+if { [info procs saved_check_compile] == [list] } {
+rename ${tool}_check_compile saved_check_compile
+proc ${tool}_check_compile { testcase option objname gcc_output } {
+ set retval [saved_check_compile $testcase $option $objname $gcc_output]
+ return 0
+}
+}
+
+# Override ${target}_load. Tests don't get this far, but it's needed
+# for GCC effective-target checks that run executables.
+foreach t $target_list {
+proc ${t}_load { args } {
+send_user "dummy load does nothing\n"
+return [list "fail" "skip execution for dummy.exp"]
+}
+}
Index: dummy-run.exp
===
--- dummy-run.exp (revision 0)
+++ dummy-run.exp (revision 0)
@@ -0,0 +1,24 @@
+
+#
+# File: dummy-run.exp
+# Author: Janis Johnson
+# Date: 2013-02-25
+#
+# Contents:
+#
+# DejaGNU board configuration file for a null target board.
+#
+
+
+load_generic_config "sim"
+set_board_info hostname "dummy-run"
+set board_info(localhost,isremote) 0
+process_multilib_options ""
+
+# Override ${target}_load to do nothing.
+foreach t $target_list {
+proc ${t}_load { args } {
+send_user "dummy load does nothing\n"
+return [list "unresolved" ""]
+}
+}
Re: dummy DejaGnu board files
On Mon, Feb 25, 2013 at 1:02 PM, Janis Johnson wrote: > I've been using a couple of DejaGnu board files to test multilibs for > which I don't have any way to execute tests, and for which I can't even > link because I don't have compatible libraries. I'd like to share but > don't know where to put them; any suggestions? Maybe in contrib/? Either a new directory or at the top. Or perhaps, just stick them in gcc/testsuite/lib with usage instructions. Diego.
Re: REG_UNUSED notes for CLOBBERs?
On Mon, Feb 25, 2013 at 10:48 AM, Eric Botcazou wrote:
>> It seems to me that a REG_UNUSED note on a CLOBBER is unnecessary, and
>> it also goes against the documented purpose of a REG_UNUSED note in
>> reg-notes.def:
>>
>> /* Identifies a register set in this insn and never used. */
>> REG_NOTE (UNUSED)
>>
>> After all, a CLOBBER is not a register set, so I think a patch like
>> the one below is necessary.
>>
>> Thoughts?
>
> This looks more like a small oversight in the DF implementation than a real
> design decision, so I'd go ahead with your patch.
That's what I believe, too. Still, combine appears to add REG_UNUSED
notes for clobbers intentionally. Do you know why it does that?
Ciao!
Steven
/* Like recog, but we receive the address of a pointer to a new pattern.
...
Modifications include deletion or addition of CLOBBERs.
PNOTES is a pointer to a location where any REG_UNUSED notes added for
the CLOBBERs are placed.
... */
static int
recog_for_combine (rtx *pnewpat, rtx insn, rtx *pnotes)
{
...
/* If we had any clobbers to add, make a new pattern than contains
them. Then check to make sure that all of them are dead. */
if (num_clobbers_to_add)
{
rtx newpat = gen_rtx_PARALLEL (VOIDmode,
rtvec_alloc (GET_CODE (pat) == PARALLEL
? (XVECLEN (pat, 0)
+ num_clobbers_to_add)
: num_clobbers_to_add + 1));
if (GET_CODE (pat) == PARALLEL)
for (i = 0; i < XVECLEN (pat, 0); i++)
XVECEXP (newpat, 0, i) = XVECEXP (pat, 0, i);
else
XVECEXP (newpat, 0, 0) = pat;
add_clobbers (newpat, insn_code_number);
for (i = XVECLEN (newpat, 0) - num_clobbers_to_add;
i < XVECLEN (newpat, 0); i++)
{
if (REG_P (XEXP (XVECEXP (newpat, 0, i), 0))
&& ! reg_dead_at_p (XEXP (XVECEXP (newpat, 0, i), 0), insn))
return -1;
if (GET_CODE (XEXP (XVECEXP (newpat, 0, i), 0)) != SCRATCH)
{
gcc_assert (REG_P (XEXP (XVECEXP (newpat, 0, i), 0)));
notes = alloc_reg_note (REG_UNUSED,
XEXP (XVECEXP (newpat, 0, i), 0), notes);
}
}
pat = newpat;
}
Re: dummy DejaGnu board files
On 2/25/2013 2:59 PM, Diego Novillo wrote: On Mon, Feb 25, 2013 at 1:02 PM, Janis Johnson wrote: I've been using a couple of DejaGnu board files to test multilibs for which I don't have any way to execute tests, and for which I can't even link because I don't have compatible libraries. I'd like to share but don't know where to put them; any suggestions? Maybe in contrib/? Either a new directory or at the top. Or perhaps, just stick them in gcc/testsuite/lib with usage instructions. Janis I have some similar ones for RTEMS targets we can't run on simulators. It wouldn't bother me if you submitted them to DejaGNU. Diego. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: REG_UNUSED notes for CLOBBERs?
> That's what I believe, too. Still, combine appears to add REG_UNUSED > notes for clobbers intentionally. Do you know why it does that? Hmm, right, it apparently clearly wants to immediately close the "live" ranges it creates by adding new clobbers. And, indeed, regrename.c for example uses these CLOBBER/REG_UNUSED pairs to compute live ranges for non-operands (the pass does its own forward scan of the insn stream). So DF's choice might have been made explicitly after all... -- Eric Botcazou
Re: REG_UNUSED notes for CLOBBERs?
On Mon, Feb 25, 2013 at 10:51 PM, Eric Botcazou wrote:
>> That's what I believe, too. Still, combine appears to add REG_UNUSED
>> notes for clobbers intentionally. Do you know why it does that?
>
> Hmm, right, it apparently clearly wants to immediately close the "live" ranges
> it creates by adding new clobbers. And, indeed, regrename.c for example uses
> these CLOBBER/REG_UNUSED pairs to compute live ranges for non-operands (the
> pass does its own forward scan of the insn stream). So DF's choice might have
> been made explicitly after all...
You mean this piece of nice code:
/* Step 4: Close chains for registers that die here, unless
the register is mentioned in a REG_UNUSED note. In that
case we keep the chain open until step #7 below to ensure
it conflicts with other output operands of this insn.
See PR 52573. Arguably the insn should not have both
notes; it has proven difficult to fix that without
other undesirable side effects. */
for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
if (REG_NOTE_KIND (note) == REG_DEAD
&& !find_regno_note (insn, REG_UNUSED, REGNO (XEXP (note, 0
{
remove_from_hard_reg_set (&live_hard_regs,
GET_MODE (XEXP (note, 0)),
REGNO (XEXP (note, 0)));
scan_rtx (insn, &XEXP (note, 0), NO_REGS, terminate_dead,
OP_IN);
}
?
Good pointer, because it lead me to:
http://gcc.gnu.org/PR52573#c6
which is the same patch as what I posted the other day.
The code in regrename.c is a different "fix" for the same PR, and it
looks to me like it's not the right fix...
On top of the REG_EQ* work, I see more REG_* notes work for GCC 4.9 :-)
Ciao!
Steven
Re: REG_UNUSED notes for CLOBBERs?
> You mean this piece of nice code:
>
> /* Step 4: Close chains for registers that die here, unless
> the register is mentioned in a REG_UNUSED note. In that
> case we keep the chain open until step #7 below to ensure
> it conflicts with other output operands of this insn.
> See PR 52573. Arguably the insn should not have both
> notes; it has proven difficult to fix that without
> other undesirable side effects. */
> for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
> if (REG_NOTE_KIND (note) == REG_DEAD
> && !find_regno_note (insn, REG_UNUSED, REGNO (XEXP (note,
> 0 {
> remove_from_hard_reg_set (&live_hard_regs,
> GET_MODE (XEXP (note, 0)),
> REGNO (XEXP (note, 0)));
> scan_rtx (insn, &XEXP (note, 0), NO_REGS, terminate_dead,
> OP_IN);
> }
>
> ?
That one is fairly recent, but I was rather referring to:
/* Process the insn, determining its effect on the def-use
chains and live hard registers. We perform the following
steps with the register references in the insn, simulating
its effect:
(1) Deal with earlyclobber operands and CLOBBERs of non-operands
by creating chains and marking hard regs live.
[...]
(7) For any REG_UNUSED, close any chains we just opened.
(7) does actually more than advertised above:
/* Step 7: Close chains for registers that were never
really used here. */
for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
if (REG_NOTE_KIND (note) == REG_UNUSED)
{
remove_from_hard_reg_set (&live_hard_regs,
GET_MODE (XEXP (note, 0)),
REGNO (XEXP (note, 0)));
So (7) also closes the live ranges of hard regs opened in (1).
--
Eric Botcazou
Re: Question on multiplied address cost computation in ivopt
On Mon, Feb 25, 2013 at 8:51 PM, Richard Biener wrote: > On Mon, Feb 25, 2013 at 11:13 AM, Bin.Cheng wrote: >> On Mon, Feb 25, 2013 at 5:39 PM, Richard Biener >> >> Another question about multiplied address is in function >> multiplier_allowed_in_address_p, it constructs rtx like "(MULT reg1, >> ratio)" and let backend determine whether multiplied address is >> allowed. I suspect the code is implemented/tested on x86, since >> machine like ARM only supports multiplied address with non-null base >> register, like "base + reg * index". The code causes multiplied >> address disabled totally for ARM machine. >> Any comments? > > Well - enhance it. Best without the need to construct an RTX in the > first place ;) I will do this along with some other IVOPT improvement. As far as I can see, constructing RTX and let backend make the decision is a general method since *_address_p has already implemented in each backend. Considering it is a backend dependent problem, I don't have better method other rtx pattern right now (to do this, new code/hook may be introduced, and they are not neat either). Of course, the rtx way has it's disadvantage that each backend only accept its own address pattern. -- Best Regards.
