Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

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

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

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

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

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

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

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

Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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,

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

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

[PATCH 0/9] RFC: selftests based on RTL dumps

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