llvm dev - Aug 2017 - RFC/bikeshedding: Separation of instruction and pattern definitions in LLVM backends

I agree with David's sentiment.  The second method appears to be easier to
follow.  IMHO, this would be easier for external users that desire to
modify the backend for their own custom extensions/instructions.

On Fri, Aug 18, 2017 at 5:05 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk
> wrote:
> On 18 Aug 2017, at 10:55, Alex Bradbury <asb at asbradbury.org>
wrote:
> >
> > I've demonstrated both the "conventional" approach
> > <https://gist.github.com/asb/0c61ebc131076c6186052c29968a49
> 1d#file-riscvinstrinfo_conventional-td>
> > and the "separate patterns" approach
> > <https://gist.github.com/asb/0c61ebc131076c6186052c29968a49
> 1d#file-riscvinstrinfo_separate_pats-td>.
> > Obviously once patterns and pseudo-instructions are separated out, you
> may
> > want to move them to a different .td file.
> >
> > Does anyone have strong views on these sort of choices one way or
> another?
>
> I do find the second easier to follow, though both are a lot easier to
> read than the MIPS back end.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170818/4d43e503/attachment-0001.html>

On 18 August 2017 at 13:02, John Leidel <john.leidel at gmail.com>
wrote:
> I agree with David's sentiment.  The second method appears to be easier
to
> follow.  IMHO, this would be easier for external users that desire to
modify
> the backend for their own custom extensions/instructions.
Hi David and John, thanks for the feedback. I realise I didn't express
my view in the original email - I also feel that the second approach
works out as cleaner. As you say, it seems plausible that the
separation will make it easier to add new custom
extensions/instructions and we expect that to be a common activity.
The main reason I'm sharing for wider feedback is to ensure there
aren't further options that haven't been considered, as it's not
going
to be painful to introduce such refactorings further down the line.

Best,

Alex

The 2nd approach does seem nicer: separates concerns, makes it easier to
extend (especially important given RISC-V's modular ISA). Although, as
David said, both seem pretty clean. One thing I would add is not too worry
about the conciseness too much initially: I have been "too clever"
before
when trying to write concise tablegen definitions, only to find that it
needlessly complicated making changes and made it difficult to follow.
Refactoring it to be more concise from a clear base is easier than the
opposite IMHO.

Best,

Jacques

On Fri, Aug 18, 2017 at 6:11 AM Alex Bradbury <asb at asbradbury.org>
wrote:
> On 18 August 2017 at 13:02, John Leidel <john.leidel at gmail.com>
wrote:
> > I agree with David's sentiment.  The second method appears to be
easier
> to
> > follow.  IMHO, this would be easier for external users that desire to
> modify
> > the backend for their own custom extensions/instructions.
>
> Hi David and John, thanks for the feedback. I realise I didn't express
> my view in the original email - I also feel that the second approach
> works out as cleaner. As you say, it seems plausible that the
> separation will make it easier to add new custom
> extensions/instructions and we expect that to be a common activity.
> The main reason I'm sharing for wider feedback is to ensure there
> aren't further options that haven't been considered, as it's
not going
> to be painful to introduce such refactorings further down the line.
>
> Best,
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170818/88993406/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4847 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170818/88993406/attachment-0001.bin>