On Tue, Aug 20, 2019 at 9:07 AM John Darrington
wrote:
>
> 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
> > wit
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 b
On Mon, Aug 19, 2019 at 8:06 PM John Darrington
wrote:
>
> 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
>
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. Unfortunatel
On Mon, Aug 19, 2019 at 09:14:22AM -0400, Vladimir Makarov wrote:
> On 2019-08-19 3:35 a.m., John Darrington wrote:
> >On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
> > No I meant something like that
> >
> > (define_special_memory_constraint "a" ...)
> > (de
On 2019-08-19 3:35 a.m., John Darrington wrote:
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" ...
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 (o
On 2019-08-16 7:23 a.m., John Darrington wrote:
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 re
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 (mem
On Thu, Aug 15, 2019 at 02:30:19PM -0400, Vladimir Makarov 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 comp
On 8/15/19 12:38 PM, Richard Biener wrote:
On August 15, 2019 6:29:13 PM GMT+02:00, Vladimir Makarov
wrote:
On 8/10/19 2:05 AM, John Darrington wrote:
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
On 8/15/19 1:35 PM, John Darrington wrote:
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/co
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 computed
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???:
/
On August 15, 2019 6:29:13 PM GMT+02:00, Vladimir Makarov
wrote:
>On 8/10/19 2:05 AM, John Darrington wrote:
>> 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
On 8/10/19 2:05 AM, John Darrington wrote:
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
On 2019-08-10 2:05 a.m., John Darrington wrote:
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
Hi John,
On Mon, Aug 12, 2019 at 08:47:43AM +0200, John Darrington wrote:
> On Sat, Aug 10, 2019 at 11:12:18AM -0500, Segher Boessenkool wrote:
> 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:
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 reload before:
>
On Sat, Aug 10, 2019 at 08:10:27AM +0200, John Darrington wrote:
> 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
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 reload before:
>48: r40:PSI=r34:PSI
>49: r41:PSI=[y:PSI+0x2f]
insn 14 is a mem-to-mem move (another featur
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 rep
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
gcc/testsuite/gcc.c-torture/
On 2019-08-09 4:14 a.m., John Darrington wrote:
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 no
On 8/9/19 2:14 AM, John Darrington wrote:
> 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
> On Aug 9, 2019, at 10:16 AM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote:
>> On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote:
>>
>> ... However I wonder if this issue is
>> related to the other major outstanding proble
Hi!
On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote:
> 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
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
date.
On 8/8/19 1:19 PM, Segher Boessenkool wrote:
> On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote:
>>
>>
>>> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool
>>> wrote:
>>>
>>> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov
On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote:
>
>
> > On Aug 8, 2019, at 1:21 PM, Segher Boessenkool
> > wrote:
> >
> > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
> >>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
> >>> The old reload (reload[1].c) sup
On Thu, Aug 08, 2019 at 01:25:27PM -0400, Paul Koning wrote:
> > On Aug 8, 2019, at 1:21 PM, Segher Boessenkool
> > wrote:
> > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
> >> Indirect addressing is a key feature in size-optimized code.
> >
> > That doesn't mean that LRA has to
On 2019-08-08 12:43 p.m., Paul Koning wrote:
On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
On 2019-08-04 3:18 p.m., John Darrington wrote:
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.
> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool
> wrote:
>
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
>>> The old reload (reload[1].c) supports such addressing. As modern
>>> mainstream architectures have no this
> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool
> wrote:
>
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
>>> The old reload (reload[1].c) supports such addressing. As modern
>>> mainstream architectures have no this
On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
> > On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
> > The old reload (reload[1].c) supports such addressing. As modern
> > mainstream architectures have no this kind of addressing, it was not
> > implemented in LRA.
>
> Is LRA
> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote:
>
>
> On 2019-08-04 3:18 p.m., John Darrington wrote:
>> 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
On 2019-08-04 3:18 p.m., John Darrington wrote:
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
37 matches
Mail list logo
