Re: Question about PR 48814 and ivopts and post-increment
On Fri, Dec 4, 2015 at 11:00 AM, Bin.Cheng wrote:
> On Fri, Dec 4, 2015 at 10:48 AM, Bin.Cheng wrote:
>> On Wed, Dec 2, 2015 at 5:11 AM, Steve Ellcey wrote:
>>>
>>> I have a question involving ivopts and PR 48814, which was a fix for
>>> the post increment operation. Prior to the fix for PR 48814, MIPS
>>> would generate this loop for strcmp (C code from glibc):
>>>
>>> $L4:
>>> lbu $3,0($4)
>>> lbu $2,0($5)
>>> addiu $4,$4,1
>>> beq $3,$0,$L7
>>> addiu $5,$5,1# This is a branch delay slot
>>> beq $3,$2,$L4
>>> subu$2,$3,$2 # This is a branch delay slot (only used after
>>> loop)
>>>
>>>
>>> With the current top-of-tree we now generate:
>>>
>>> addiu $4,$4,1
>>> $L8:
>>> lbu $3,-1($4)
>>> addiu $5,$5,1
>>> beq $3,$0,$L7
>>> lbu $2,-1($5) # This is a branch delay slot
>>> beq $3,$2,$L8
>>> addiu $4,$4,1# This is a branch delay slot
>>>
>>> subu$2,$3,$2 # Done only once now after exiting loop.
>>>
>>> The main problem with the new loop is that the beq comparing $2 and $3
>>> is right before the load of $2 so there can be a delay due to the time
>>> that the load takes. The ideal code would probably be:
>>>
>>> addiu $4,$4,1
>>> $L8:
>>> lbu $3,-1($4)
>>> lbu $2,0($5) # This is a branch delay slot
>>> beq $3,$0,$L7
>>> addiu $5,$5,1
>>> beq $3,$2,$L8
>>> addiu $4,$4,1# This is a branch delay slot
>>>
>>> subu$2,$3,$2 # Done only once now after exiting loop.
>>>
>>> Where we load $2 earlier (using a 0 offset instead of a -1 offset) and
>>> then do the increment of $5 after using it in the load. The problem
>>> is that this isn't something that can just be done in the instruction
>>> scheduler because we are changing one of the instructions (to modify the
>>> offset) in addition to rearranging them and I don't think the instruction
>>> scheduler supports that.
>> Hmm, I think Bernd introduced sched_flag !DONT_BREAK_DEPENDENCIES to
>> resolve dependence by modifying address expression. I think this is
>> the same problem, what's needed is to model dependence using that
>> framework. Maybe delay slot is special here?
>>
>>>
>>> It looks like is the ivopts code that decided to increment the registers
>>> first and use the -1 offsets in the loads after instead of using 0 offsets
>>> and then incrementing the offsets after the loads but I can't figure out
>>> how or why ivopts made that decision.
>>>
>>> Does anyone have any ideas on how I could 'fix' GCC to make it generate
>>> the ideal code? Is there some way to do it in the instruction scheduler?
>>> Is there some way to modify ivopts to fix this by modifying the cost
>> It's likely IVO just peaks the first candidate when it runs into a
>> tie. Could you please post preprocessed source code so that I can
>> have a look? I am not familiar with glibc. Thanks.
> Oh, I saw the example in another thread of yours.
>
Dump before IVO is as below:
:
# s1_1 = PHI
# s2_2 = PHI
s1_6 = s1_1 + 1;
c1_8 = *s1_1;
s2_9 = s2_2 + 1;
c2_10 = *s2_2;
if (c1_8 == 0)
goto ;
else
goto ;
And the iv candidates are as:
candidate 1 (important)
var_before ivtmp.6
var_after ivtmp.6
incremented before exit test
type unsigned int
base (unsigned int) p1_4(D)
step 1
base object (void *) p1_4(D)
candidate 2 (important)
original biv
type const unsigned char *
base (const unsigned char *) p1_4(D)
step 1
base object (void *) p1_4(D)
candidate 3 (important)
var_before ivtmp.7
var_after ivtmp.7
incremented before exit test
type unsigned int
base (unsigned int) p2_5(D)
step 1
base object (void *) p2_5(D)
candidate 4 (important)
original biv
type const unsigned char *
base (const unsigned char *) p2_5(D)
step 1
base object (void *) p2_5(D)
Generally GCC would choose normal candidates {1, 3} and insert
increment before exit condition. This is expected in this case. But
when there is applicable original candidates {2, 4}, GCC would prefer
these in order to achieve better debugging. Also as I suspected,
[reg] and [reg-1] have same address cost on mips, that's why GCC makes
current decision.
Thanks,
bin
Re: building gcc with macro support for gdb?
On 3 December 2015 at 16:01, Martin Sebor wrote: > On 12/02/2015 06:48 PM, Peter Bergner wrote: >> >> On Wed, 2015-12-02 at 20:05 -0500, Ryan Burn wrote: >>> >>> Is there any way to easily build a stage1 gcc with macro support for >>> debugging? >>> >>> I tried setting CFLAGS, and CXXFLAGS to specify "-O0 -g3" via the >>> command line before running configure, but that only includes those >>> flags for some of the compilation steps. >>> >>> I was only successful after I manually edited the makefile to replace >>> "-g" with "-g3". >> >> >> Try CFLAGS_FOR_TARGET='-O0 -g3 -fno-inline' and CXXFLAGS_FOR_TARGET='-O0 >> -g3 -fno-inline' > > > I've been using STAGE1_CFLAGS as Andreas suggested. The tree > checks in GCC make heavy use of macros that GDB unfortunately > often has trouble with. See GDB bugs 19111, 1888, and 18881 > for some of the problems. To get around these, I end up using > info macro to print the macro definition and using whatever it > expands to instead. I wonder if someone has found a more > convenient workaround. GDB's python printers might be useful here, but someone would have to do the work of re-defining the macros in python, and maybe keeping them up to date with changes to the macros.
GCC 5.4 Status report (2015-12-04)
Status == The GCC 5 branch is open again for regression and documentation fixes. If nothing unusual happens you can expect GCC 5.4 somewhen closely before GCC 6 is released. Quality Data Priority # Change from last report --- --- P10 P2 109- 12 P3 28+ 8 P4 85- 2 P5 32 --- --- Total P1-P3 137+ 4 Total 254- 6 Previous Report === https://gcc.gnu.org/ml/gcc/2015-11/msg00113.html
Re: GCC 5.4 Status report (2015-12-04)
Will there be another 4.9 release, too? I'm really hoping that branch can stay open a bit, since I can't upgrade to the new std::string implementation yet. On Fri, Dec 4, 2015 at 8:29 AM, Richard Biener wrote: > > Status > == > > The GCC 5 branch is open again for regression and documentation fixes. > If nothing unusual happens you can expect GCC 5.4 somewhen closely > before GCC 6 is released. > > > Quality Data > > > Priority # Change from last report > --- --- > P10 > P2 109- 12 > P3 28+ 8 > P4 85- 2 > P5 32 > --- --- > Total P1-P3 137+ 4 > Total 254- 6 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2015-11/msg00113.html
Re: GCC 5.4 Status report (2015-12-04)
On Fri, 4 Dec 2015, NightStrike wrote: Will there be another 4.9 release, too? I'm really hoping that branch can stay open a bit, since I can't upgrade to the new std::string implementation yet. Uh? The new ABI in libstdc++ is supposed to be optional, you can still use the old std::string in gcc-5, can't you? -- Marc Glisse
Re: GCC 5.4 Status report (2015-12-04)
On Fri, Dec 4, 2015 at 2:37 PM, Marc Glisse wrote: > On Fri, 4 Dec 2015, NightStrike wrote: > >> Will there be another 4.9 release, too? I'm really hoping that branch >> can stay open a bit, since I can't upgrade to the new std::string >> implementation yet. Yes, there will be another 4.9 release as well. Usually we close the 4.9 branch with a last release somewhen after GCC 6 is released. Richard. > > Uh? The new ABI in libstdc++ is supposed to be optional, you can still use > the old std::string in gcc-5, can't you? > > -- > Marc Glisse
Re: GCC 5.4 Status report (2015-12-04)
On Fri, Dec 04, 2015 at 02:37:46PM +0100, Marc Glisse wrote: > On Fri, 4 Dec 2015, NightStrike wrote: > > >Will there be another 4.9 release, too? I'm really hoping that branch > >can stay open a bit, since I can't upgrade to the new std::string > >implementation yet. > > Uh? The new ABI in libstdc++ is supposed to be optional, you can still use > the old std::string in gcc-5, can't you? Sure, you can either configure gcc 5 so that it defaults to the new or old ABI, and you can always also override it through command line options. As for another 4.9 release, yes, there will be 4.9.4 at some point at least. Jakub
GCC 5.3 Released
The GNU Compiler Collection version 5.3 has been released. GCC 5.3 is a bug-fix release from the GCC 5 branch containing important fixes for regressions and serious bugs in GCC 5.2 with more than 143 bugs fixed since the 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 them individually!
Re: building gcc with macro support for gdb?
> "Martin" == Martin Sebor writes: Martin> To get around these, I end up using info macro to print the Martin> macro definition and using whatever it expands to instead. I Martin> wonder if someone has found a more convenient workaround. For some of these, like the __builtin_offsetof and __null problems, you can add a new "macro define" to gcc's gdbinit.in. In fact I already see __null there, so maybe you don't have the correct add-auto-load-safe-path setting in your ~/.gdbinit. Tom
Re: Question about PR 48814 and ivopts and post-increment
On Fri, 2015-12-04 at 16:22 +0800, Bin.Cheng wrote:
> Dump before IVO is as below:
>
> :
> # s1_1 = PHI
> # s2_2 = PHI
> s1_6 = s1_1 + 1;
> c1_8 = *s1_1;
> s2_9 = s2_2 + 1;
> c2_10 = *s2_2;
> if (c1_8 == 0)
> goto ;
> else
> goto ;
>
> And the iv candidates are as:
> candidate 1 (important)
> var_before ivtmp.6
> var_after ivtmp.6
> incremented before exit test
> type unsigned int
> base (unsigned int) p1_4(D)
> step 1
> base object (void *) p1_4(D)
> candidate 2 (important)
> original biv
> type const unsigned char *
> base (const unsigned char *) p1_4(D)
> step 1
> base object (void *) p1_4(D)
> candidate 3 (important)
> var_before ivtmp.7
> var_after ivtmp.7
> incremented before exit test
> type unsigned int
> base (unsigned int) p2_5(D)
> step 1
> base object (void *) p2_5(D)
> candidate 4 (important)
> original biv
> type const unsigned char *
> base (const unsigned char *) p2_5(D)
> step 1
> base object (void *) p2_5(D)
>
> Generally GCC would choose normal candidates {1, 3} and insert
> increment before exit condition. This is expected in this case. But
> when there is applicable original candidates {2, 4}, GCC would prefer
> these in order to achieve better debugging. Also as I suspected,
> [reg] and [reg-1] have same address cost on mips, that's why GCC makes
> current decision.
>
> Thanks,
> bin
Yes, I agree that [reg] and [reg-1] have the same address cost, but
using [reg-1] means that the increment of reg happens before the access
and that puts the load of [reg-1] closer to the use of the value loaded
and that causes a stall. If we used [reg] and incremented it after the
load then we would have at least one instruction in between the load and
the use and either no stall or a shorter stall.
I don't know if ivopts has anyway to do this type of analysis when
picking the IV.
Steve Ellcey
sell...@imgtec.com
