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

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?

In my opinion, generating parts of the td files is much less error prone and
more convenient for us than having to write the insns definitions by hand
(that would indeed need "maintenance".)

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

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

> -----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 Fri, Aug 3, 2012 at 12:02 PM, Jakob Stoklund Olesen <stoklund at
2pi.dk> wrote:
>> 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.
I am only speaking about the Hexagon*.td files: I fail to see how generating
these from our a higher level representation of the Hexagon Instruction Set
manuals is "defeat[ing] the purpose of open source".  Let's not
turn this
technical review into an "what is open source" thread.
> 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.
Just curious: what deficiencies in LLVM do you think we working around here?

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