> 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
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.
Ok, but please don't put non-public issue numbers in the comments.
Ok. Thanks!
Ok. Thanks!
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,
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
> 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
> 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
> 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 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.
> OK to apply ?
Ok.
> OK to apply ?
Ok.
> 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
>
This is OK. Thanks!
> * 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
Yup, these are OK. Thanks!
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
> 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
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
> 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!
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.
> 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
> =
36 matches
Mail list logo
