On 24/03/14 04:44, Jeff Law wrote:
On 03/22/14 05:29, Richard Hulme wrote:
On 22/03/14 01:47, Jeff Law wrote:
On 03/21/14 18:35, DJ Delorie wrote:
I've found that "removing uneeded moves through registers" is
something gcc does poorly in the post-reload optimizers. I've written
my own on som
On 03/22/14 05:38, Richard Hulme wrote:
Can you explain what is too weird about it in particular? It certainly
has restrictions on which registers can be used with various
instructions but I wouldn't have thought they were that complicated that
they couldn't be described using the normal constr
On 03/22/14 05:29, Richard Hulme wrote:
On 22/03/14 01:47, Jeff Law wrote:
On 03/21/14 18:35, DJ Delorie wrote:
I've found that "removing uneeded moves through registers" is
something gcc does poorly in the post-reload optimizers. I've written
my own on some occasions (for rl78 too). Perhaps
On 22/03/14 01:35, DJ Delorie wrote:
Is it possible that the virtual pass causes inefficiencies in some
cases by sticking with r8-r31 when one of the 'normal' registers
would be better?
That's not a fair question to ask, since the virtual pass can *only*
use r8-r31. The first bank has to be le
On 22/03/14 01:47, Jeff Law wrote:
On 03/21/14 18:35, DJ Delorie wrote:
I've found that "removing uneeded moves through registers" is
something gcc does poorly in the post-reload optimizers. I've written
my own on some occasions (for rl78 too). Perhaps this is a good
starting point to look at
On 03/21/14 18:35, DJ Delorie wrote:
I've found that "removing uneeded moves through registers" is
something gcc does poorly in the post-reload optimizers. I've written
my own on some occasions (for rl78 too). Perhaps this is a good
starting point to look at?
much needless copying, which str
> Is it possible that the virtual pass causes inefficiencies in some
> cases by sticking with r8-r31 when one of the 'normal' registers
> would be better?
That's not a fair question to ask, since the virtual pass can *only*
use r8-r31. The first bank has to be left alone else the
devirtualizer b
On 11/03/14 01:40, DJ Delorie wrote:
I'm curious. Have you tried out other approaches before you decided
to go with the virtual registers?
Yes. Getting GCC to understand the "unusual" addressing modes the
RL78 uses was too much for the register allocator to handle. Even
when the addressing m
On Sun, 2014-03-16 at 17:22 -0400, DJ Delorie wrote:
> This is similar to what I had to do for msp430 - I made a new
> constraint that was what general_operand would have done if it allowed
> volatile MEMs, and used that for instructions where a volatile's
> volatileness wouldn't be broken.
Maybe
This is similar to what I had to do for msp430 - I made a new
constraint that was what general_operand would have done if it allowed
volatile MEMs, and used that for instructions where a volatile's
volatileness wouldn't be broken.
> Maybe we should add a target hook/macro to control this to avoid
> duplicated code of 'general_operand' in various places?
Even in the msp430, not all patterns can be safely used with volatile
MEMs (i.e. the macro patterns). So, not all general_operand's were
replaced.
On Sun, 2014-03-16 at 19:48 +0100, Richard Hulme wrote:
> On 10/03/14 22:37, DJ Delorie wrote:
> >
> > The use of "volatile" disables many of GCC's optimizations. I
> > consider this a bug in GCC, but at the moment it needs to be "fixed"
> > in the backends on a case-by-case basis.
> >
>
> Hi,
>
On 10/03/14 22:37, DJ Delorie wrote:
The use of "volatile" disables many of GCC's optimizations. I
consider this a bug in GCC, but at the moment it needs to be "fixed"
in the backends on a case-by-case basis.
Hi,
I've looked into the differences between the steps taken when using a
variabl
> I'm curious. Have you tried out other approaches before you decided
> to go with the virtual registers?
Yes. Getting GCC to understand the "unusual" addressing modes the
RL78 uses was too much for the register allocator to handle. Even
when the addressing modes are limited to "usual" ones, G
DJ,
On Mon, 2014-03-10 at 20:17 -0400, DJ Delorie wrote:
> > Ah, that certainly explains a lot. How exactly would the fixing be
> > done? Is there an example I could look at for one of the other processors?
>
> No, RL78 is the first that uses this scheme.
I'm curious. Have you tried out othe
> Ah, that certainly explains a lot. How exactly would the fixing be
> done? Is there an example I could look at for one of the other processors?
No, RL78 is the first that uses this scheme.
> I calculated a week or two ago that we could make a code-saving of
> around 8% by using near or rel
On 10/03/14 22:37, DJ Delorie wrote:
I've managed to build GCC myself so that I could experiment a bit
but as this is my first foray into compiler internals, I'm
struggling to work out how things fit together and what affects
what.
The key thing to know about the RL78 backend, is that it has tw
> I've managed to build GCC myself so that I could experiment a bit
> but as this is my first foray into compiler internals, I'm
> struggling to work out how things fit together and what affects
> what.
The key thing to know about the RL78 backend, is that it has two
"targets" it uses. For the f
18 matches
Mail list logo
