llvm dev - Aug 2012 - [LLVMdev] TableGen related question for the Hexagon backend

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Jakob Stoklund Olesen
> Sent: Friday, August 03, 2012 10:02 AM
> To: Sebastian Pop
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] TableGen related question for the Hexagon
> backend
> 
> 
> On Aug 2, 2012, at 11:24 PM, Sebastian Pop <spop at codeaurora.org>
wrote:
> 
> > On Thu, Aug 2, 2012 at 5:23 PM, Jakob Stoklund Olesen
> <stoklund at 2pi.dk> wrote:
> >> The problem is, this isn't really any better than having a
large
> switch statement. You just moved the table into the .td file.
> >>
> >> You should be taking advantage of the instruction multiclasses so
> you don't have to maintain a full table of opcodes.
> >
> > We wouldn't need to "maintain" this table of opcodes, as
this table
> is
> > extracted from a higher level representation of the instruction set.
> > In particular, this table would not need to be modified at all for
> the
> > existing supported processors, and any new version of processors will
> > have its table automatically generated by us.
> >
> > Why wouldn't it be acceptable for the *.td files defining the
> instructions
> > and the relations between them to be generated and not written by
> hand?
> 
> Because it defeats the purpose of open source.
> 
> It would be impossible to improve the way Hexagon models instructions
> without changing these tables, and if they are just intermediate build
> products generated from secret 'real' sources, it is much more
> difficult.
> 
> This is supposed to be a collaboration that makes LLVM better for
> everybody. If you are just working around deficiencies in LLVM's tools
> instead of trying to improve them, there is really no point in sharing
> that work.
> 
> /Jakob
[Villmow, Micah] Just curious as we have a similar approach for some code in our
backed, but if the higher level source and the scripts to produce the
intermediates were provided, would that be sufficiently acceptable to using
generated td files?
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Aug 3, 2012, at 10:11 AM, "Villmow, Micah" <Micah.Villmow at
amd.com> wrote:
> [Villmow, Micah] Just curious as we have a similar approach for some code
in our backed, but if the higher level source and the scripts to produce the
intermediates were provided, would that be sufficiently acceptable to using
generated td files?
No.

It's perfectly fine if the initial version of the td files are generated by
a script, but td files in the LLVM tree need to be the primary source you work
on going forward.

It think you would be better served by having a way of verifying the correctness
of td files using your canonical architecture description. See for example
Richard Barton's talk from the April developer meeting.

/jakob

On Fri, Aug 3, 2012 at 1:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>
wrote:
>
> On Aug 3, 2012, at 10:11 AM, "Villmow, Micah" <Micah.Villmow
at amd.com> wrote:
>
>> [Villmow, Micah] Just curious as we have a similar approach for some
code in our backed, but if the higher level source and the scripts to produce
the intermediates were provided, would that be sufficiently acceptable to using
generated td files?
>
> No.
>
> It's perfectly fine if the initial version of the td files are
generated by a script, but td files in the LLVM tree need to be the primary
source you work on going forward.
>
Ok, I think we are reaching here a middle ground.  I think
that our scripts can detect redundancies and can zip the zillion
classes into multiclass hierarchies that would enable us to move
forward: evolving the code by hand and the result would also be
more readable for humans.
> It think you would be better served by having a way of verifying the
correctness of td files using your canonical architecture description. See for
example Richard Barton's talk from the April developer meeting.
>
Very good point: we can still use our scripts for verification purposes.
Thanks for your useful remarks and guidance.

Sebastian
-- 
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum