On Tue, 2016-09-20 at 09:20 -0600, Jeff Law wrote:
> On 09/20/2016 08:34 AM, Bernd Schmidt wrote:
> > On 09/20/2016 04:32 PM, David Malcolm wrote:
> > >
> > > To summarize so far: you want every pseudo to have its regno
> > > dumped
> > > with a 'p' prefix, and renumber them on dump (and then on l
On 09/20/2016 05:20 PM, Jeff Law wrote:
On 09/20/2016 08:34 AM, Bernd Schmidt wrote:
(reg/f:DI v1 virtual-stack-vars)
this.
Doesn't the same apply to the number of virtual stack regs? Those are
in the same array as pseudos. So ISTM we prefix in the dump, but do
adjustment of the number
On 09/20/2016 08:34 AM, Bernd Schmidt wrote:
On 09/20/2016 04:32 PM, David Malcolm wrote:
To summarize so far: you want every pseudo to have its regno dumped
with a 'p' prefix, and renumber them on dump (and then on load).
OK.
Renumbering is not helpful because it interferes with the view you
On 09/20/2016 04:32 PM, David Malcolm wrote:
To summarize so far: you want every pseudo to have its regno dumped
with a 'p' prefix, and renumber them on dump (and then on load).
OK.
Renumbering is not helpful because it interferes with the view you have
in the debugger. So, IMO just a prefix,
On Mon, 2016-09-19 at 11:35 -0600, Jeff Law wrote:
> On 09/16/2016 03:27 PM, David Malcolm wrote:
> > > We should also twiddle how we represent registers in the dumps.
> > > Identifying hard regs by name (so we can map back to a hard reg
> > > if
> > > the
> > > hard regs change), identifying pseud
On 09/16/2016 03:27 PM, David Malcolm wrote:
We should also twiddle how we represent registers in the dumps.
Identifying hard regs by name (so we can map back to a hard reg if
the
hard regs change), identifying pseudos by number that isn't affected
if
the hard register set changes ie, p0, p1, p2,
On 09/16/2016 11:12 PM, David Malcolm wrote:
There are some interrelated questions here:
(a) where do the dumps live? (string fragments embedded in the source
file vs external files)
(b) -fself-test vs DejaGnu tests that use a real frontend. In the
latter case, is the frontend "rtl1", or an exte
On Fri, 2016-09-16 at 14:05 -0600, Jeff Law wrote:
> On 09/13/2016 05:15 AM, Bernd Schmidt wrote:
> > >
> > > Note that the loader now resets INSN_CODE to -1, regardless of
> > > the
> > > actual code passed in, to force re-recognition, and to isolate
> > > the
> > > dumps somewhat from changes to
On Fri, 2016-09-16 at 14:00 -0600, Jeff Law wrote:
> On 09/14/2016 02:37 AM, Richard Biener wrote:
> >
> > Note that while the "snippets" may largely work (not sure how many
> > you tried to come up with) I see the issue that a lot of RTL "unit
> > tests" would need some trees set up, like to prop
On 09/13/2016 05:15 AM, Bernd Schmidt wrote:
Note that the loader now resets INSN_CODE to -1, regardless of the
actual code passed in, to force re-recognition, and to isolate the
dumps somewhat from changes to the .md files. So although the above
says insn 641 and 642 (for some snapshot of the
On 09/14/2016 02:37 AM, Richard Biener wrote:
Note that while the "snippets" may largely work (not sure how many
you tried to come up with) I see the issue that a lot of RTL "unit
tests" would need some trees set up, like to properly form MEM_EXPRs
or REG_DECL or even SYMBOL_REFs. So I fear tha
On 09/13/2016 01:15 PM, Bernd Schmidt wrote:
On 09/12/2016 08:57 PM, David Malcolm wrote:
I'm not sure I follow - this sounds like a dedicated target for
selftesting.
Would it be a separate configuration i.e. something like:
../src/configure --target=rtl-selftest
or somesuch?
The way I im
On Tue, Sep 13, 2016 at 10:37 PM, Jeff Law wrote:
> On 09/12/2016 12:57 PM, David Malcolm wrote:
>>
>>
>> I'm not sure I follow - this sounds like a dedicated target for
>> selftesting.
>
> That's exactly what it is. We'd essentially put in knobs so that we could
> control the different things we
On 09/12/2016 12:57 PM, David Malcolm wrote:
I'm not sure I follow - this sounds like a dedicated target for
selftesting.
That's exactly what it is. We'd essentially put in knobs so that we
could control the different things we need to. For example, if we
wanted to test a particular problem
On 09/12/2016 08:57 PM, David Malcolm wrote:
I'm not sure I follow - this sounds like a dedicated target for
selftesting.
Would it be a separate configuration i.e. something like:
../src/configure --target=rtl-selftest
or somesuch?
The way I imagine it working, the top-level Makefile would
On Mon, 2016-09-12 at 16:10 +0200, Bernd Schmidt wrote:
> In general, it's functionality that I would very much like to have
> (although maybe it's less useful these days now that the rtl side is
> fairly static). I think there's not much sense looking too deeply at
> the
> individual patches ye
In general, it's functionality that I would very much like to have
(although maybe it's less useful these days now that the rtl side is
fairly static). I think there's not much sense looking too deeply at the
individual patches yet; we need to first figure out what we would really
like this to
The current selftest code is adequate for testing individual
instructions, but most interesting passes have logic involving the
interaction of multiple instructions, or require a CFG and function
to be runnable. In theory we could write selftests by programatically
constructing a function and CFG
18 matches
Mail list logo
