> OK to apply ?
Ok. Thanks!
> gcc/ChangeLog
> 2015-08-05 Nick Clifton
>
> * config/rl78/rl78.c (rl78_rtx_costs): Treat MULT insns as cheap
> if optimizing for size.
>
> Index: gcc/config/rl78/rl78.c
> ===
> RCS f
Hi DJ,
This is OK, but note that it prevents some operations like:
__far int i;
foo()
{
i ++;
}
from being implemented with a minimum set of opcodes. This might be
particularly troublesome for volatile far things.
Right - it is something I will have to look into.
Cheers
Nick
Hi DJ,
The patch below fixes a small problem with the RL78 backend. When
optimizing for size it is better to use a slow multiply instruction
than a faster, but larger, shift sequence. So the patch tweaks the
rtx costs for MULT insns when speed is not a priority.
Tested with no regress
This is OK, but note that it prevents some operations like:
__far int i;
foo()
{
i ++;
}
from being implemented with a minimum set of opcodes. This might be
particularly troublesome for volatile far things.
Hi DJ,
It turns out that the optimization in rl78_force_nonfar_3 to allow
some special cases to be kept in far pointers does not always work.
The test case included with this patch will trigger ICEs if the
optimization is allowed to persist.
So, may I check this patch in please ?
Cheer
Ok, but please don't put non-public issue numbers in the comments.
Hi DJ,
This patch adds a small optimization to the RL78 addsi3 pattern so
that it can skip adding in the high part of a constant symbolic
address when -mes0 is active. Under these circumstances we know that
the address has to be in low memory and that it is invalid to attempt
to access
Ok. Thanks!
Hi DJ,
The -mes0 option for the RL78 backend should put read only data into a
special .frodata section, but unfortunately my recent update to the
rl78_select_section function broke this behaviour. Below is a patch
to fix this. Tested with no regressions on an rl78-elf toolchain.
OK to
Ok. Thanks!
Hi DJ,
This patch contains two small improvements for the RL78 compiler:
1. A peephole to match:
movwax, !
movwbc, ax
callbc
with:
movwax, !
callax
2. A change to avoid pushing the frame pointer register in an
interru
Hi DJ,
Ok but..
+case SECCAT_TBSS:
+ return default_select_section (decl, reloc, align);
+
+default:
+ gcc_unreachable ();
Would it be better to just "default:" everything to
default_select_section, instead of enumerating everything we know
about today?
Yes it would. :-}
> OK to apply ?
Ok but..
> +case SECCAT_TBSS:
> + return default_select_section (decl, reloc, align);
> +
> +default:
> + gcc_unreachable ();
Would it be better to just "default:" everything to
default_select_section, instead of enumerating everything we know
about today?
Hi DJ,
Currently the RL78 port does not place zero-initialised data in the
.bss section. This is because of the rl78_select_section() function
which does not handle bss data. The patch below updates the function
to handle that and other types of data so that they end up in the
expected
Hi DJ,
OK to apply ?
Ok, but...
Thanks - committed.
- if (regno == FRAME_POINTER_REGNUM && frame_pointer_needed)
+ if (regno == FRAME_POINTER_REGNUM
+ && (frame_pointer_needed || df_regs_ever_live_p (regno)))
Do we want regs_ever_live or regs_ever_written_to ? I seem to recall
> OK to apply ?
Ok, but...
> - if (regno == FRAME_POINTER_REGNUM && frame_pointer_needed)
> + if (regno == FRAME_POINTER_REGNUM
> + && (frame_pointer_needed || df_regs_ever_live_p (regno)))
Do we want regs_ever_live or regs_ever_written_to ? I seem to recall
changing a port... mep per
Hi DJ,
Below is a small patch to fix a small problem with the need_to_save()
function in the RL78 backend. It was only marking the frame pointer
register as needing a save if the frame pointer was in use. But since
the frame pointer is call-saved it needs to be saved any time it is
use
Hi Jan-Benedict.
../../../gcc/gcc/config/rl78/rl78.c:390:14: error: enumeration value ‘MUL_RL78’
not handled in switch [-Werror=switch]
switch (rl78_mul_type)
../../../gcc/gcc/config/rl78/rl78.c:4649:34: error: unused parameter ‘x’
[-Werror=unused-parameter]
rl78_preferred_reload_
> OK to apply ?
Ok.
> gcc/ChangeLog
> 2015-04-15 Nick Clifton
>
> * config/rl78/rl78-opts.h (enum rl78_mul_types): Add MUL_G14 and
> MUL_UNINIT.
> (enum rl78_cpu_type): New.
> * config/rl78/rl78-virt.md (attr valloc): Add divhi and divsi.
> (umulhi3_shift_virt
Hi DJ,
The attached patch adds support for the RL78 divide and modulus
capabilities (both as an instruction in G14 cores and as a hardware
peripheral in G13 cores). It also updates the multiply patterns to
add clobbers of the AX and BC registers, which helps fix some reload
problems wit
> OK to apply ?
Ok!
> 2015-04-14 Nick Clifton
>
> * config/rl78/rl78.c (rl78_expand_prologue): Mark large stack
> decrement instruction as being frame related.
> (rl78_print_operand_1): Handle 'p' modifier to add +0 to HL
> based addresses.
> If zero extendi
Hi DJ,
I would like permission to apply this patch to the RL78 backend. It
tidies up a few minor bugs, specifically:
* The prologue instruction to increment the stack pointer by a large
amount was not being marked as frame related.
* The %p operand operator was not using %code
> The problem appears to be that GCC will create a multiply-plus-add
> instruction to access the table regardless of whether the backend
> supports such an instruction. I could not work out where in the
> middle end this was occurring, so instead I created the patch below
> which contai
> OK to apply ?
Ok.
Hi DJ,
Compiling this test case with the RL78 toolchain results in an ICE:
unsigned char g_X;
unsigned char g_Y;
const __far unsigned char TabA[2][2] = { { 3, 0 }, { 4, 5 } };
void main (void) { g_X = 1; g_Y = TabA[g_X][g_X]; }
The problem appears to be that GCC will create a
Hi DJ,
Compiling a program with one of the real RL78 registers marked as
call-used (eg via -fcall-used-ax), can trigger an internal compiler
error. Although modifying the ABI in this way may not be a good idea,
it is still wrong that the compiler generates an ICE.
The patch below fixes
Hi Jan-Benedict,
Seems you accidentally committed quite some more code you're currently
working on in that very commit, which is now breaking
Doh! Yes, sorry about that. I have now reverted the DIV attribute part
of the patch. (I am hoping that this work will be ready for
contributing soo
On Wed, 2015-02-04 11:14:16 +, Nick Clifton wrote:
> Please can I apply the patch below to fix some RL78 gcc testsuite
> failures ?
[...]
> The second fix is to the RL78 specific dead-code elimination pass
> which was failing to note the REGs inside a MEM are used when that MEM
> is
Ok.
Hi DJ,
Please can I apply the patch below to fix some RL78 gcc testsuite
failures ?
The patch does two things: Firstly in the RL78 assembler version of
the __addsf3 function it fixes a corner case where rounding up the
fraction results in an overflow into an unused bit. The problem h
> OK to apply ?
Ok.
> OK to apply ?
Ok.
Hi DJ,
The attached patch provides some enhancements to libgcc for the RL78.
It includes faster and smaller versions of the bit counting and simple
floating point functions, and a version of the integer multiply
support function designed to work on the G10.
Tested on an rl78-elf toolcha
Hi DJ,
The patch below contains two minor enhancements for the RL78 prologue
and epilogue code. The first is for when a large amount of local
stack space needs to be allocated. Rather than generating a long
sequence of SUB SP, # instructions, the patched codes moves SP
into AX, perform
> Here is a small patch to fix a code-gen problem for the RL78. The bug
> was that the register death pass was not looking inside PARALLELs, and
> thus missing some USE and SET cases. I considered adding code to scan
> all of the elements in the PARALLEL, but the only ones that can be
>
Hi DJ,
Here is a small patch to fix a code-gen problem for the RL78. The bug
was that the register death pass was not looking inside PARALLELs, and
thus missing some USE and SET cases. I considered adding code to scan
all of the elements in the PARALLEL, but the only ones that can be
g
This is OK. Thanks!
Hi DJ,
The patch below is to fix a snafu I made whilst fixing some problems
with the RL78 port a while ago. GCC was generating
(SUBREG (SYMBOL_REF) ) which made no sense to me, so I had the
movqi expander just fail when it encountered them. Now that I have
more idea about why they are
> * config/rl78/rl78-real.md (cbranchsi4_real_signed): Add
> anti-cacnonical alternatives.
> (negandhi3_real): New pattern.
> * config/rl78/rl78-virt.md (negandhi3_virt): New pattern.
These are fine, although I don't know why gcc would require a negandhi3
pattern...
Hi DJ,
I'm OK with adding patterns in general, but I wonder if gcc would
produce better code if they were split into QImode ops earlier?
Probably. In fact I double checked and I can no longer find the tests
that triggered the need for the new "andhi3" and "xorhi3" patterns, so
the revised p
I'm OK with adding patterns in general, but I wonder if gcc would
produce better code if they were split into QImode ops earlier?
+ [(set (match_operand:HI 0 "register_operand" "=Av")
+ (and:HI (match_operand:HI 1 "register_operand" "0")
+ (match_operand:HI 2 "immed
Hi DJ,
The patch below adds some missing instruction patterns to the RL78
backend. Missing in the sense that gcc generates the RTL even
if the patterns are not present in the backend and then triggers an
ICE because they cannot be matched. It is not clear to me why this
should be happe
Yup, these are OK. Thanks!
Hi DJ,
I noticed a couple of RL78 patches in our local tree that ought to be
upstream, so here they are. The first is for the size of the frame
pointer register and the second is for the UMUL instruction when both
input operands are in the same register.
OK to apply ?
Cheers
Nick
g
This one is OK.
> 2013-05-16 Nick Clifton
>
> * config/rl78/rl78.c (rl78_attribute_table): Add naked.
> (rl78_is_naked_func): New function.
> (rl78_expand_prologue): Skip prologue generation for naked
> functions.
> (rl78_expand_epilogue): Skip epilogue g
Hi DJ,
OK, I am abandoning my RL78 interrupt prologue patch for now. There
are just too many complications to make it work. Instead here is a
much simpler patch to add support for a naked function attribute.
OK to apply ?
Cheers
Nick
gcc/ChangeLog
2013-05-16 Nick Clifton
> Yes - in fact this appears to be a general problem with RL78 interrupt
> handlers. There are no instructions to push/pop the current bank
> selection, so in order for nested interrupt handlers to work they would
> have to do something like:
The bank select bits are in PSW, which is automati
Hi DJ,
* Uses register bank 3 instead of register bank 0 inside the
handler.
I wonder if nested interrupts will cause problems, since the second
interrupt will occur with RB3 already selected.
Yes - in fact this appears to be a general problem with RL78 interrupt
handlers. Ther
> * Uses register bank 3 instead of register bank 0 inside the
> handler.
I wonder if nested interrupts will cause problems, since the second
interrupt will occur with RB3 already selected.
Also, there are some hand-coded routines in libgloss/libgcc that
manually swap banks, they'd hav
Hi DJ,
The patch below makes some changes to the way the RL78 backend handles
the generation of interrupt functions. Specifically it:
* Uses register bank 3 instead of register bank 0 inside the
handler.
* Tweaks the need_to_save() function so only those registers that
w
The problem is, devirt hasn't happened yet when we compute the frame
size, so we *can't* know if bank 0 registers are used yet.
Also, I've had problems recomputing the frame size after reload. If
the frame size changes for *any* reason between reload and prologue,
you get corrupt code, as the el
Hi DJ,
I am submitting a patch on behalf of Renesas and KPIT. They found a
way to improve the prologues for interrupt handlers so that only the
registers that actually need to be saved are pushed onto the stack.
The patch has been tested with no regressions in the gcc testsuite for
an
> Please may I apply the patch below. It fixes the RL78 backend so that
> the stack register can be used as a base address register.
Yes, please. Thanks!
Hi DJ,
Please may I apply the patch below. It fixes the RL78 backend so that
the stack register can be used as a base address register.
Tested with no regressions on an rl78-elf toolchain.
Cheers
Nick
PS. I am currently investigating allow r8-r15 to be used as base
registers.
gcc/Cha
I did notice that the hardware didn't work the same way as the
documentation... this would explain it. Yes, please apply it :-)
I think that's right, since the ISR return restores the flag register,
which has the bank select bits in it.
Hi DJ,
There is a error in the RL78 G13 hardware manual. Section 14, Figure
14-3 lists the values of the MDBL registers as 4H, 5H and the
MDBH registers as 6H, 7H. This is incorrect. The correct
values are shown in Section 3, Table 3-5: MDBL => 6H, 7H,
MDBH =>
Hi DJ,
Since interrupts can happen at any time, it is possible for a ISR to
be called when register bank 0 is not the currently selected bank.
Hence the prologue for an interrupt handler should always select bank
0 before saving any registers. The patch below makes sure that this
happen
> OK for mainline/4.7 branch ?
Ok with me
Hi Eric,
> On 04/04/12 12:24, Eric Botcazou wrote:
You probably need to adjust gcc.dg/stack-usage-1.c too.
s/flag_stack_usage/flag_stack_usage_info/
Thanks for the corrections. Revised patch attached.
OK for mainline/4.7 branch ?
Cheers
Nick
gcc/ChangeLog
2012-04-04 Nick Clifton
> Please could I apply the patch below to the RL78 port ? It adds
> support for generating stack use info with the -fstack-usage option.
You probably need to adjust gcc.dg/stack-usage-1.c too.
> Index: gcc/config/rl78/rl78.c
> =
Hi DJ,
Please could I apply the patch below to the RL78 port ? It adds
support for generating stack use info with the -fstack-usage option.
Also - may I apply this patch to the 4.7 branch as well please ?
Cheers
Nick
gcc/ChangeLog
2012-04-04 Nick Clifton
* config/rl78/rl78.
62 matches
Mail list logo
