On May 1, 2007, at 3:28 PM, Nate Begeman wrote:
On May 1, 2007, at 12:24 PM, Christopher Lamb wrote:
Hi Nate,
Could you look into the possibility of re-using the sub/super
register support that Evan recently added? This may prevent much
duplication of information in the RegisterInfo.td, especially for
targets with vector registers that have many subregisters.
It certainly would, I agree.
I believe that sub/super register generator unions the set of sub/
super registers in a deterministic fashion and produces the
necessary tables in the RegisterInfo.inc already. The only thing is
that this would make the sub register index implicit in the
ordering of the sub register list in the RegisterInfo.td.
I'm not sure things are sufficiently well ordered internally for
that, or sorted in any particular fashion. I'll look into it, but it
seems like it would be less flexible and make the td files far less
intuitive as to what is actually going on. If tablegen picked the
numbering, I would have to go read the generated file to know what to
write in the ISel for that backend, which seems backwards to me.
I see the problem in generating the ISel. Perhaps it would be be best
to go the other way and have the sub/super reg sets be determined by
the the explicit sets defined. My goal was simply to eliminate
redundant, and possibly erroneously conflicting information from the
file. Right now there are two different ways to specify sub
registers, and if they don't match there could be problems.
Also, would it be possible to emit the information gathered as
table lookups rather than a massive two level switch statement? I
believe all the information to get the necessary mappings should be
available.
It would be possible, but seems like significantly more work. I'm
sure it will be possible to improve upon the initial implementation,
which should be good enough to address most of the issues blocked by
the lack of subregs exposed to the selection dag.
Thanks for working on this. I didn't expect to get it addressed for
quite a while!
--
Christopher Lamb
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
