date:20191213

Project Agreement

2019-12-13 Thread Lacy Johnson

Good Morning, i wish to discuss a business agreement with you. Kindly revert 
immediately. Via Mr Fu Hxuang CEO

Project Agreement

2019-12-13 Thread Lacy Johnson

Good Morning, i wish to discuss a business agreement with you. Kindly revert 
immediately. Via Mr Fu Hxuang CEO

Re: Code bloat due to silly IRA cost model?

2019-12-13 Thread Georg-Johann Lay


Am 11.12.19 um 18:55 schrieb Richard Sandiford:

Georg-Johann Lay  writes:

Hi, doesn't actually anybody know know to make memory more expensive
than registers when it comes to allocating registers?

Whatever I am trying for TARGET_MEMORY_MOVE_COST and
TARGET_REGISTER_MOVE_COST, ira-costs.c always makes registers more
expensive than mem and therefore allocates values to stack slots instead
of keeping them in registers.

Test case (for avr) is as simple as it gets:

float func (float);

float call (float f)
{
  return func (f);
}

What am I missing?

Johann


Georg-Johann Lay schrieb:

Hi,

I am trying to track down a code bloat issue and am stuck because I do
not understand IRA's cost model.

The test case is as simple as it gets:

float func (float);

float call (float f)
{
 return func (f);
}

IRA dump shows the following insns:


(insn 14 4 2 2 (set (reg:SF 44)
 (reg:SF 22 r22 [ f ])) "bloat.c":4:1 85 {*movsf}
  (expr_list:REG_DEAD (reg:SF 22 r22 [ f ])
 (nil)))
(insn 2 14 3 2 (set (reg/v:SF 43 [ f ])
 (reg:SF 44)) "bloat.c":4:1 85 {*movsf}
  (expr_list:REG_DEAD (reg:SF 44)
 (nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:SF 22 r22)
 (reg/v:SF 43 [ f ])) "bloat.c":5:12 85 {*movsf}
  (expr_list:REG_DEAD (reg/v:SF 43 [ f ])
 (nil)))
(call_insn/j 7 6 8 2 (parallel [

#14 sets pseudo 44 from arg register R22.
#2 moves it to pseudo 43
#6 moves it to R22 as it prepares for call_insn #7.

There are 2 allocnos and cost:

Pass 0 for finding pseudo/allocno costs

 a1 (r44,l0) best NO_REGS, allocno NO_REGS
 a0 (r43,l0) best NO_REGS, allocno NO_REGS

   a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
   a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000

which is quite odd because MEM is way more expensive here than any REG.

Okay, so let's boost the MEM cost (TARGET_MEMORY_MOVE_COST) by a factor
of 100:

 a1 (r44,l0) best NO_REGS, allocno NO_REGS
 a0 (r43,l0) best NO_REGS, allocno NO_REGS

   a0(r43,l0) costs: ADDW_REGS:320 SIMPLE_LD_REGS:320
LD_REGS:320 NO_LD_REGS:320 GENERAL_REGS:320 MEM:801000
   a1(r44,l0) costs: ADDW_REGS:320 SIMPLE_LD_REGS:320
LD_REGS:320 NO_LD_REGS:320 GENERAL_REGS:320 MEM:801000

What??? The REG costs are 100 times higher, and stille higher that the
MEM costs.  What the heck is going on?

Setting TARGET_REGISTER_MOVE_COST and also TARGET_MEMORY_MOVE_COST to 0
yiels:

   a0(r43,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 LD_REGS:0 NO_LD_REGS:0
GENERAL_REGS:0 MEM:0
   a1(r44,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 LD_REGS:0 NO_LD_REGS:0
GENERAL_REGS:0 MEM:0

as expected, i.e. there is no other hidden source of costs considered by
IRA.  And even TARGET_REGISTER_MOVE_COST = 0  and
TARGET_MEMORY_MOVE_COST = original gives:

   a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
   a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000

How the heck do I tell ira-costs that registers are way cheaper than MEM?


I think this is coming from:

   /* FIXME: Ideally, the following test is not needed.
 However, it turned out that it can reduce the number
 of spill fails.  AVR and it's poor endowment with
 address registers is extreme stress test for reload.  */

   if (GET_MODE_SIZE (mode) >= 4
   && regno >= REG_X)
 return false;


This was introduced to "fix" unable to find a register to spill ICE.

What I do not understand is that the code with long (which is SImode on 
avr) is fine:


long lunc (long);

long callL (long f)
{
return lunc (f);
}

callL:
rjmp lunc;  7   [c=24 l=1]  call_value_insn/3



in avr_hard_regno_mode_ok.  This forbids SFmode in r26+ and means that
moves between pointer registers and general registers have the highest
possible cost (65535) to prevent them for being used for SFmode.  So:

ira_register_move_cost[SFmode][POINTER_REGS][GENERAL_REGS] = 65535;

The costs for union classes are the maximum (worst-case) cost of
for each subclass, so this means that:

ira_register_move_cost[SFmode][GENERAL_REGS][GENERAL_REGS] = 65535;

as well.


This means that, when there is an expensive class (because it only 
contains one register for example), then it will blow the cost of 
GENERAL_REGS to crazy values no matter what?


What's also strange is that the register allocator would not need to 
allocate a register at all:  The incoming parameter comes in SI:22 and 
is just be passed through to the callee, which also receives the value 
in SI:22.  Why would one move that value to memory?  Even if memory was 
cheaper, moving the value to mem just to load it again to the same 
register is not very sensible...  because in almost any case, /no/ 
in

Re: Code bloat due to silly IRA cost model?

2019-12-13 Thread Richard Sandiford

Georg-Johann Lay  writes:
> Am 11.12.19 um 18:55 schrieb Richard Sandiford:
>> Georg-Johann Lay  writes:
>>> Hi, doesn't actually anybody know know to make memory more expensive
>>> than registers when it comes to allocating registers?
>>>
>>> Whatever I am trying for TARGET_MEMORY_MOVE_COST and
>>> TARGET_REGISTER_MOVE_COST, ira-costs.c always makes registers more
>>> expensive than mem and therefore allocates values to stack slots instead
>>> of keeping them in registers.
>>>
>>> Test case (for avr) is as simple as it gets:
>>>
>>> float func (float);
>>>
>>> float call (float f)
>>> {
>>>   return func (f);
>>> }
>>>
>>> What am I missing?
>>>
>>> Johann
>>>
>>>
>>> Georg-Johann Lay schrieb:
 Hi,

 I am trying to track down a code bloat issue and am stuck because I do
 not understand IRA's cost model.

 The test case is as simple as it gets:

 float func (float);

 float call (float f)
 {
  return func (f);
 }

 IRA dump shows the following insns:


 (insn 14 4 2 2 (set (reg:SF 44)
  (reg:SF 22 r22 [ f ])) "bloat.c":4:1 85 {*movsf}
   (expr_list:REG_DEAD (reg:SF 22 r22 [ f ])
  (nil)))
 (insn 2 14 3 2 (set (reg/v:SF 43 [ f ])
  (reg:SF 44)) "bloat.c":4:1 85 {*movsf}
   (expr_list:REG_DEAD (reg:SF 44)
  (nil)))
 (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
 (insn 6 3 7 2 (set (reg:SF 22 r22)
  (reg/v:SF 43 [ f ])) "bloat.c":5:12 85 {*movsf}
   (expr_list:REG_DEAD (reg/v:SF 43 [ f ])
  (nil)))
 (call_insn/j 7 6 8 2 (parallel [

 #14 sets pseudo 44 from arg register R22.
 #2 moves it to pseudo 43
 #6 moves it to R22 as it prepares for call_insn #7.

 There are 2 allocnos and cost:

 Pass 0 for finding pseudo/allocno costs

  a1 (r44,l0) best NO_REGS, allocno NO_REGS
  a0 (r43,l0) best NO_REGS, allocno NO_REGS

a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
 NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
 NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000

 which is quite odd because MEM is way more expensive here than any REG.

 Okay, so let's boost the MEM cost (TARGET_MEMORY_MOVE_COST) by a factor
 of 100:

  a1 (r44,l0) best NO_REGS, allocno NO_REGS
  a0 (r43,l0) best NO_REGS, allocno NO_REGS

a0(r43,l0) costs: ADDW_REGS:320 SIMPLE_LD_REGS:320
 LD_REGS:320 NO_LD_REGS:320 GENERAL_REGS:320 MEM:801000
a1(r44,l0) costs: ADDW_REGS:320 SIMPLE_LD_REGS:320
 LD_REGS:320 NO_LD_REGS:320 GENERAL_REGS:320 MEM:801000

 What??? The REG costs are 100 times higher, and stille higher that the
 MEM costs.  What the heck is going on?

 Setting TARGET_REGISTER_MOVE_COST and also TARGET_MEMORY_MOVE_COST to 0
 yiels:

a0(r43,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 LD_REGS:0 NO_LD_REGS:0
 GENERAL_REGS:0 MEM:0
a1(r44,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 LD_REGS:0 NO_LD_REGS:0
 GENERAL_REGS:0 MEM:0

 as expected, i.e. there is no other hidden source of costs considered by
 IRA.  And even TARGET_REGISTER_MOVE_COST = 0  and
 TARGET_MEMORY_MOVE_COST = original gives:

a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
 NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
 NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000

 How the heck do I tell ira-costs that registers are way cheaper than MEM?
>> 
>> I think this is coming from:
>> 
>>/* FIXME: Ideally, the following test is not needed.
>>  However, it turned out that it can reduce the number
>>  of spill fails.  AVR and it's poor endowment with
>>  address registers is extreme stress test for reload.  */
>> 
>>if (GET_MODE_SIZE (mode) >= 4
>>&& regno >= REG_X)
>>  return false;
>
> This was introduced to "fix" unable to find a register to spill ICE.
>
> What I do not understand is that the code with long (which is SImode on 
> avr) is fine:
>
> long lunc (long);
>
> long callL (long f)
> {
>  return lunc (f);
> }
>
> callL:
>   rjmp lunc;  7   [c=24 l=1]  call_value_insn/3

This is due to differences in the way that lower-subreg.c lowers
SF moves vs. SI moves.  For SI it generates pure QI moves and so
gets rid of the SI entirely.  For SF it still builds the QI values
back into an SF:

  || (!SCALAR_INT_MODE_P (dest_mode)
  && !resolve_reg_p (dest)
  && !resolve_subreg_p (dest)))

I imagine this is because non-int modes are held in FPRs rather than
GPRs on most targets, but TBH I'm not sure.  I couldn't see a comment
that explains the above decision.

With -fno-split-wide-type

Re: Code bloat due to silly IRA cost model?

2019-12-13 Thread Segher Boessenkool

On Fri, Dec 13, 2019 at 12:45:47PM +, Richard Sandiford wrote:
> combine's to blame for the fact that we have two pseudo registers rather
> than one.  See the comments about the avr-elf results in:
> 
>https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02150.html
> 
> for more details.

It's not combine's fault if register allocation does a bad job.  And we
should *not* generate worse code in combine just because it exposes a
problem in RA (with 2-2 and make_more_copies we generate better code on
average, on all targets I tested, 50 or so).

If having two pseudos here is not an advantage, then RA should optimise
one away.  It does usually, why not here?

Segher

Re: Code bloat due to silly IRA cost model?

2019-12-13 Thread Richard Sandiford

Segher Boessenkool  writes:
> On Fri, Dec 13, 2019 at 12:45:47PM +, Richard Sandiford wrote:
>> combine's to blame for the fact that we have two pseudo registers rather
>> than one.  See the comments about the avr-elf results in:
>> 
>>https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02150.html
>> 
>> for more details.
>
> It's not combine's fault if register allocation does a bad job.  And we
> should *not* generate worse code in combine just because it exposes a
> problem in RA (with 2-2 and make_more_copies we generate better code on
> average, on all targets I tested, 50 or so).
>
> If having two pseudos here is not an advantage, then RA should optimise
> one away.  It does usually, why not here?

I didn't say it was combine's fault that RA was bad.  I said it was
combine's fault that we have two pseudos rather than one.

Richard

Re: Code bloat due to silly IRA cost model?

2019-12-13 Thread Segher Boessenkool

On Fri, Dec 13, 2019 at 04:22:11PM +, Richard Sandiford wrote:
> Segher Boessenkool  writes:
> > On Fri, Dec 13, 2019 at 12:45:47PM +, Richard Sandiford wrote:
> >> combine's to blame for the fact that we have two pseudo registers rather
> >> than one.  See the comments about the avr-elf results in:
> >> 
> >>https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02150.html
> >> 
> >> for more details.
> >
> > It's not combine's fault if register allocation does a bad job.  And we
> > should *not* generate worse code in combine just because it exposes a
> > problem in RA (with 2-2 and make_more_copies we generate better code on
> > average, on all targets I tested, 50 or so).
> >
> > If having two pseudos here is not an advantage, then RA should optimise
> > one away.  It does usually, why not here?
> 
> I didn't say it was combine's fault that RA was bad.  I said it was
> combine's fault that we have two pseudos rather than one.

But that is not a fault, that is on purpose.

Before this change, combine would forward hard registers into pseudos
greedily.  RA can do a better job than that.  If you found a case where
RA does not do a good job, let's fix that?

(And combine does get rid of two pseudos, if that is a good idea to do.
If instructions do not properly combine, it can not, of course).


Segher

Re: Code bloat due to silly IRA cost model?

2019-12-13 Thread Richard Sandiford

Segher Boessenkool  writes:
> On Fri, Dec 13, 2019 at 04:22:11PM +, Richard Sandiford wrote:
>> Segher Boessenkool  writes:
>> > On Fri, Dec 13, 2019 at 12:45:47PM +, Richard Sandiford wrote:
>> >> combine's to blame for the fact that we have two pseudo registers rather
>> >> than one.  See the comments about the avr-elf results in:
>> >> 
>> >>https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02150.html
>> >> 
>> >> for more details.
>> >
>> > It's not combine's fault if register allocation does a bad job.  And we
>> > should *not* generate worse code in combine just because it exposes a
>> > problem in RA (with 2-2 and make_more_copies we generate better code on
>> > average, on all targets I tested, 50 or so).
>> >
>> > If having two pseudos here is not an advantage, then RA should optimise
>> > one away.  It does usually, why not here?
>> 
>> I didn't say it was combine's fault that RA was bad.  I said it was
>> combine's fault that we have two pseudos rather than one.
>
> But that is not a fault, that is on purpose.
>
> Before this change, combine would forward hard registers into pseudos
> greedily.  RA can do a better job than that.

I don't think anyone's disputing that.  You quoted the initial text
above out of context.  Johann had asked why the RA even needed to do
anything for the posted testcase, where we have the equivalent of
"foo (bar ())", bar returns a value in register X and foo takes an
argument in register X.  I was trying to explain that we still need:

  (set pseudo X)
  ...
  (set X pseudo)

in order to avoid spill failures in all but trivial cases, and that we
rely on the RA to make a good allocation choice for the pseudo.  So I
think what you said above is basically explaining back to me what I'd
said in the context that was snipped.

But we only need one temporary pseudo register to avoid the spill
failures, whereas in Johann's case the RA sees two:

  (set pseudo2 X)
  (set pseudo pseudo2)
  ...
  (set X pseudo2)

My point was the extra pseudo<-pseudo2 move is created by combine for
its own internal purposes and pseudo2 isn't something *the RA* needs to
avoid spill failures.  But in this case combine fails to fold the extra
move with anything and so the move "leaks out" to later passes, including
RA.  The snipped context linked to the message where we'd discussed this,
including why combine fails to restore the original X<-pseudo<-X chain
for avr-elf.  It also shows that avr-elf code improved significantly
if we *did* restore that original chain (which the new combine pass
happened to do, although that just fell out in the wash rather than
being a specific aim).

In a perfect world, we could keep adding more and more pseudos to a
move chain without affecting the output of the RA.  But it's not too
surprising if that isn't always true in practice.  After all, the
point of adding pseudo2 in the first place is that *combine* handles
pseudo<-pseudo2<-X differently from just pseudo<-X. ;-)

Thanks,
Richard

> If you found a case where
> RA does not do a good job, let's fix that?
>
> (And combine does get rid of two pseudos, if that is a good idea to do.
> If instructions do not properly combine, it can not, of course).
>
>
> Segher

gcc-8-20191213 is now available

2019-12-13 Thread gccadmin

Snapshot gcc-8-20191213 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20191213/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 279387

You'll find:

 gcc-8-20191213.tar.xzComplete GCC

  SHA256=62d700eb2432a70fa581621549ba6c6c39866ef37102700151aa8ef0d8ca706a
  SHA1=383d5e25a054133ba56b26c497d776938028b286

Diffs from 8-20191206 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
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.

can not found mcp/mpfr/gmp, but i has installed them.

2019-12-13 Thread 刘加权

  cmd 1 : ./configure --disable-multilib  --prefix=/usr/local 
--with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local &&  make -j4 
&& sudo make install
  cmd 2 : ./configure --disable-multilib  --prefix=/usr/local  &&  make -j4 && 
sudo make install

after I installed mpfr mpc  gmp , I use  --with-mpc=/usr/local to set the path,
but configure give me the error blew:

checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations.  Source code for these libraries can be found at
their respective hosting sites as well as at
ftp://gcc.gnu.org/pub/gcc/infrastructure/.  See also
http://gcc.gnu.org/install/prerequisites.html for additional info.  If
you obtained GMP, MPFR and/or MPC from a vendor distribution package,
make sure that you have installed both the libraries and the header
files.  They may be located in separate packages.


but I already installed  mpfr mpc and gmp into /usr/local directory, ls show 
like blew:

vi@linx:/usr/local$ ls
etc  games  gmssl  include  intranet_security  lib  man  sbin  share  src
vi@linx:/usr/local$ ls include/
gmp.h  libelf  mpc.h  mpf2mpfr.h  mpfr.h
vi@linx:/usr/local$ ls lib
libelf.a   libelf.so.0   libgmp.a   libgmp.so libgmp.so.10.3.2  
libmpc.la  libmpc.so.3  libmpfr.a   libmpfr.so
libmpfr.so.6.0.2  pkgconfig  python2.6
libelf.so  libelf.so.0.8.12  libgmp.la  libgmp.so.10  
libmpc.a  libmpc.so  libmpc.so.3.1.0  libmpfr.la  
libmpfr.so.6  ocaml python2.5  site_ruby
vi@linx:/usr/local$ pwd
/usr/local
vi@linx:/usr/local$


then I try configure without set mpc,mpfr and gmp location by use cmd 2: 
./configure --disable-multilib  --prefix=/usr/local  &&  make -j4 && sudo make 
install
it gives me the right configure result and then I can run make to buid the gcc 
7.3.0

I want to know the reason. and where is wrong? thank you very much, guys!

My system is Debian 6, codename is squeeze.

Project Agreement

Project Agreement

Re: Code bloat due to silly IRA cost model?

Re: Code bloat due to silly IRA cost model?

Re: Code bloat due to silly IRA cost model?

Re: Code bloat due to silly IRA cost model?

Re: Code bloat due to silly IRA cost model?

Re: Code bloat due to silly IRA cost model?

gcc-8-20191213 is now available

can not found mcp/mpfr/gmp, but i has installed them.

10 matches

Site Navigation

Mail list logo

Footer information