Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

2019-08-16 Thread John Darrington
On Thu, Aug 15, 2019 at 02:23:45PM -0400, Vladimir Makarov wrote: > I tried this solution earlier. But unfortunately it makes things worse. What happens is it libgcc cannot > even be built -- ICEs occur on a memory from address reg insn such as: > (insn 117 2981 3697 5 (set

Re: Indirect memory addresses vs. lra

2019-08-12 Thread John Darrington
On Sat, Aug 10, 2019 at 11:12:18AM -0500, Segher Boessenkool wrote: Hi! On Sat, Aug 10, 2019 at 08:05:53AM +0200, John Darrington wrote: > Choosing alt 5 in insn 14: (0) m (1) m {*movsi} >14: [r40:PSI+0x20]=[r41:PSI] > Inserting insn relo

Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

2019-08-19 Thread John Darrington
On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote: No I meant something like that (define_special_memory_constraint "a" ...) (define_predicate "my_special_predicate" ... { if (lra_in_progress_p) return REG_P

Re: Indirect memory addresses vs. lra

2019-08-15 Thread John Darrington
On Thu, Aug 15, 2019 at 12:29:13PM -0400, Vladimir Makarov wrote: Thank you for providing the sources.?? It helped me to understand what is going on.?? So the test crashes on /home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In function ???f1???:

Re: Indirect memory addresses vs. lra

2019-08-15 Thread John Darrington
On Thu, Aug 15, 2019 at 06:38:30PM +0200, Richard Biener wrote: Couldn't we spill the frame pointer? Basically we should be able to compute the first address into a reg, spill that, do the second (both could require the frame pointer), spill the frame pointer, reload the first

Re: Indirect memory addresses vs. lra

2019-08-10 Thread John Darrington
On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote: If you provide LRA dump for such test (it is better to use -fira-verbose=15 to output full RA info into stderr), I probably could say more. I've attached such a dump (generated from

Re: Indirect memory addresses vs. lra

2019-08-10 Thread John Darrington
On Fri, Aug 09, 2019 at 09:16:44AM -0500, Segher Boessenkool wrote: Is your code in some branch in our git? No. But it could be pushed there if people think it would be appropriate to do so, and if I'm given the permissions to do so. Or in some other public git? It's in my

Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

2019-08-19 Thread John Darrington
On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote: > ? As I remember there were a few other ideas from Richard Biener and > Segher Boessenkool.? I also proposed to add a new address register which > will be always a fixed stack memory slot at the end.

Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

2019-08-20 Thread John Darrington
On Tue, Aug 20, 2019 at 08:56:39AM +0200, Richard Biener wrote: > Most of these suggestions involve adding some sort of virtual registers > So I hacked the machine description to add two new registers Z1 and Z2 > with the same mode as X and Y. > > Obviously the assembler

Re: Indirect memory addresses vs. lra

2019-08-09 Thread John Darrington
On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: Yea, it's certainly designed with the more mainstream architectures in mind. THe double-indirect case that's being talked about here is well out of the mainstream and not a feature of anything LRA has targetted to

Indirect memory addresses vs. lra

2019-08-04 Thread John Darrington
I'm trying to write a back-end for an architecture (s12z - the ISA you can download from [1]). This arch accepts indirect memory addresses. That is to say, those of the form (mem (mem (...))) and although my TARGET_LEGITIMATE_ADDRESS function returns true for such addresses, LRA insists on

Re: [PATCH 2/3] GDB: Add support for 24 bit addresses

2018-08-24 Thread John Darrington
On Fri, Aug 24, 2018 at 04:34:11PM -0400, Simon Marchi wrote: (CCing gcc-patches because of the change in include/dwarf2.h) This file is owned by GCC (see the MAINTAINERS file at the top of binutils-gdb). To get a modification in it, you would need to provide a patch to

[PATCH] Add a dwarf unit type to represent 24 bit values.

2018-08-27 Thread John Darrington
* include/dwarf2.h (enum dwarf_unit_type) [DE_EH_PE_udata3]: New member. --- include/dwarf2.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dwarf2.h b/include/dwarf2.h index cf0039a92a..0fe88a3a7e 100644 --- a/include/dwarf2.h +++ b/include/dwarf2.h @@ -474,6 +474,7 @@ enum

Re: [PATCH] Add a dwarf unit type to represent 24 bit values.

2018-09-10 Thread John Darrington
On Mon, Sep 10, 2018 at 03:36:26PM +0100, Jason Merrill wrote: On Mon, Aug 27, 2018 at 8:20 PM, John Darrington wrote: > * include/dwarf2.h (enum dwarf_unit_type) [DE_EH_PE_udata3]: New member. What's the rationale? Do you have a separate patch that u

Re: [PATCH] Add a dwarf unit type to represent 24 bit values.

2018-09-08 Thread John Darrington
Ping! Does anyone have any objections or comments? J'

Re: [PATCH] Add a dwarf unit type to represent 24 bit values.

2018-09-19 Thread John Darrington
Thank you for your insight. I will investigate further and see if I can find out what is going on. J' On Thu, Sep 13, 2018 at 01:33:34PM -0400, Jason Merrill wrote: Well, that's curious, given that GCC doesn't have that address type either. Ah, looking closer, I see that we

Re: [PATCH] Add a dwarf unit type to represent 24 bit values.

2018-09-12 Thread John Darrington
On Mon, Sep 10, 2018 at 04:40:58PM +0100, Jason Merrill wrote: On Mon, Sep 10, 2018 at 3:42 PM, John Darrington wrote: > On Mon, Sep 10, 2018 at 03:36:26PM +0100, Jason Merrill wrote: > On Mon, Aug 27, 2018 at 8:20 PM, John Darrington >

[PATCH] simplify-rtx.c: Change BITSIZE to UNIT_PRECISION in simplification of (extend ashiftrt (ashift ..))) Otherwise the gcc_assert can catch when dealing with partial int modes.

2019-07-03 Thread John Darrington
--- gcc/ChangeLog | 6 ++ gcc/simplify-rtx.c | 8 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index c206ab6..47035ca 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,9 @@ +2019-07-03 John Darrington + + simplify

[PATCH] simplify-rtx.c (simplify_unary_operation_1): Change BITSIZE to PRECISION.

2019-07-08 Thread John Darrington
insertions(+), 4 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 5d3d359..919b9e9 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,9 @@ +2019-07-04 John Darrington + + simplify-rtx.c: Change BITSIZE to UNIT_PRECISION in simplification of + (extend ashiftrt (ashift

Re: [PATCH] simplify-rtx.c: Change BITSIZE to UNIT_PRECISION in simplification

2019-07-03 Thread John Darrington
On Wed, Jul 03, 2019 at 04:32:54PM -0600, Jeff Law wrote: John, I assume you're doing this for an out of tree port (s12z?)? That is correct. Otherwise it'd also be useful if you could include a test which triggers the assert. Once I have the other aspects of the port sorted out