From: Joern Rennecke <amylaar@cygnus.co.uk>
To: zack@rabi.columbia.edu (Zack Weinberg)
Cc: law@cygnus.com, amylaar@cygnus.co.uk, egcs@egcs.cygnus.com
Subject: Re: a strange infelicity of register allocation
Date: Tue, 26 Jan 1999 07:44:00 -0000 [thread overview]
Message-ID: <199901261544.PAA21115@phal.cygnus.co.uk> (raw)
In-Reply-To: <199901252130.QAA07655@blastula.phys.columbia.edu>
> There is questionable code elsewhere, such as:
>
> decl -4112(%ebp)
> movl -4112(%ebp),%ecx
This is a CISC specific problem - load-store architectures don't see it since
they have to do a load first for the decrement, and then can inherit from the
store.
I think it could be tackled by something I'd call 'reverse inheritance' - you
remember when could have used the value in a register, and when you later
find a load of the same value, and the register is free from the desired use
to the load, the load can be moved upwards.
However, in some cases - like this one - this strategy increases code size
and issue bandwidth, so its use has to be conditionalized on ! optimize_size
and on compiling for a processor where simplicity of operations is more
important than the mere instruction count.
> C:
> buf = xrealloc (buf, op - buf);
> fp->buf = buf;
> return op - buf;
>
> becomes
>
> movl %ebx,%eax
> subl -4104(%ebp),%eax
> pushl %eax
> movl -4104(%ebp),%edx
> pushl %edx
> call xrealloc
> movl %eax,-4104(%ebp)
> movl 12(%ebp),%eax
> movl -4104(%ebp),%ecx
> movl %ecx,(%eax)
> subl %ecx,%ebx
> movl %ebx,%eax
> jmp epilogue
The first problem here is that (op - buf) hasn't been subjected to cse.
Is the address of buf taken anywhere in this function?
WARNING: multiple messages have this Message-ID
From: Joern Rennecke <amylaar@cygnus.co.uk>
To: zack@rabi.columbia.edu (Zack Weinberg)
Cc: law@cygnus.com, amylaar@cygnus.co.uk, egcs@egcs.cygnus.com
Subject: Re: a strange infelicity of register allocation
Date: Sun, 31 Jan 1999 23:58:00 -0000 [thread overview]
Message-ID: <199901261544.PAA21115@phal.cygnus.co.uk> (raw)
Message-ID: <19990131235800.BE4kZEw_rkJi7_iM5r1-4ZJp7pneaLdmEBTSrrrQIi0@z> (raw)
In-Reply-To: <199901252130.QAA07655@blastula.phys.columbia.edu>
> There is questionable code elsewhere, such as:
>
> decl -4112(%ebp)
> movl -4112(%ebp),%ecx
This is a CISC specific problem - load-store architectures don't see it since
they have to do a load first for the decrement, and then can inherit from the
store.
I think it could be tackled by something I'd call 'reverse inheritance' - you
remember when could have used the value in a register, and when you later
find a load of the same value, and the register is free from the desired use
to the load, the load can be moved upwards.
However, in some cases - like this one - this strategy increases code size
and issue bandwidth, so its use has to be conditionalized on ! optimize_size
and on compiling for a processor where simplicity of operations is more
important than the mere instruction count.
> C:
> buf = xrealloc (buf, op - buf);
> fp->buf = buf;
> return op - buf;
>
> becomes
>
> movl %ebx,%eax
> subl -4104(%ebp),%eax
> pushl %eax
> movl -4104(%ebp),%edx
> pushl %edx
> call xrealloc
> movl %eax,-4104(%ebp)
> movl 12(%ebp),%eax
> movl -4104(%ebp),%ecx
> movl %ecx,(%eax)
> subl %ecx,%ebx
> movl %ebx,%eax
> jmp epilogue
The first problem here is that (op - buf) hasn't been subjected to cse.
Is the address of buf taken anywhere in this function?
next prev parent reply other threads:[~1999-01-26 7:44 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-23 22:42 Zack Weinberg
1999-01-25 4:56 ` Joern Rennecke
1999-01-25 11:47 ` Zack Weinberg
1999-01-25 11:50 ` Joern Rennecke
1999-01-31 23:58 ` Joern Rennecke
1999-01-25 12:00 ` Jeffrey A Law
1999-01-25 13:14 ` John S. Dyson
1999-01-31 23:58 ` John S. Dyson
1999-01-25 13:31 ` Zack Weinberg
1999-01-25 13:36 ` Jeffrey A Law
1999-01-25 19:56 ` Zack Weinberg
1999-01-25 20:33 ` Jeffrey A Law
1999-01-25 20:41 ` Zack Weinberg
1999-01-25 20:53 ` Jeffrey A Law
1999-01-25 21:18 ` Zack Weinberg
1999-01-25 21:30 ` Jeffrey A Law
1999-01-25 21:38 ` Zack Weinberg
1999-01-26 4:59 ` Jeffrey A Law
1999-01-27 9:26 ` Zack Weinberg
1999-01-28 5:26 ` Jeffrey A Law
1999-01-28 17:20 ` Zack Weinberg
1999-01-28 17:33 ` Joern Rennecke
1999-01-28 18:01 ` Jeffrey A Law
1999-01-28 18:27 ` Zack Weinberg
1999-01-28 19:58 ` Jeffrey A Law
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Jeffrey A Law
1999-01-26 7:44 ` Joern Rennecke [this message]
1999-01-27 8:35 ` Zack Weinberg
1999-01-27 9:08 ` Joern Rennecke
1999-01-27 9:52 ` Zack Weinberg
1999-01-27 11:49 ` Marc Espie
1999-01-31 23:58 ` Marc Espie
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Joern Rennecke
1999-01-28 8:11 ` Jeffrey A Law
1999-01-28 11:40 ` Zack Weinberg
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Joern Rennecke
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Jeffrey A Law
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58 ` Joern Rennecke
1999-01-31 23:58 ` Zack Weinberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199901261544.PAA21115@phal.cygnus.co.uk \
--to=amylaar@cygnus.co.uk \
--cc=egcs@egcs.cygnus.com \
--cc=law@cygnus.com \
--cc=zack@rabi.columbia.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).