Displaying 4 results from an estimated 4 matches for "tbglen".
Did you mean:
tbgen
2009 Apr 20
2
[LLVMdev] A few questions from a newbie
...ion.
When I try to match it using the pattern [(set Int32Regs::reg,
tglobaladdr::mem_addr)]. the code generated by tblgen cannot be compiled
because there will be a switch statement that contains two cases for the
'tglobaladdr', one is hard-coded in by tblgen and the other is generated by
tbglen following the pattern I specified. The compilation fails because of
the two duplicated and conflicting cases.
When I try to match it using the pattern [(set Int32Regs::reg,
globaladdr::mem_addr)], the corresponding DAG node generated does not take
the mem_addr as an input. As a matter of fact, it...
2009 Apr 20
0
[LLVMdev] A few questions from a newbie
...using the pattern [(set Int32Regs::reg,
> tglobaladdr::mem_addr)]. the code generated by tblgen cannot be
> compiled because there will be a switch statement that contains two
> cases for the 'tglobaladdr', one is hard-coded in by tblgen and the
> other is generated by tbglen following the pattern I specified. The
> compilation fails because of the two duplicated and conflicting cases.
This happened to me too. I stole a solution from the other targets -
create a wrapper node:
def BfinWrapper: SDNode<"BfinISD::Wrapper", SDTIntUnaryOp>;
Then cust...
2009 Apr 20
2
[LLVMdev] A few questions from a newbie
...attern [(set Int32Regs::reg,
> > tglobaladdr::mem_addr)]. the code generated by tblgen cannot be
> > compiled because there will be a switch statement that contains two
> > cases for the 'tglobaladdr', one is hard-coded in by tblgen and the
> > other is generated by tbglen following the pattern I specified. The
> > compilation fails because of the two duplicated and conflicting cases.
>
> This happened to me too. I stole a solution from the other targets -
> create a wrapper node:
>
> def BfinWrapper: SDNode<"BfinISD::Wrapper", SDTIn...
2017 May 27
4
Should we split llvm Support and ADT?
It would be better, because a debug tablegen is slower than an optimized
tablegen, but it's still slow and it doesn't address the problem that
tablegen runs *at all* when it doesn't really need to. I think if tablegen
wasn't running all the time we could incremental builds down from 15
minutes (and that's on my really powerful machine) to under 5, which seemed
like a big