<div dir="ltr"><div><div><div><div><div><div><div>Hi Krzysztof,<br><br></div>uint64_t is not enough for me. seems that 128bit is enough for me.<br></div><div>what I am doing is like I need to define the register set for 16 working threads in a warp in nvidia terminology. I often call the 'warp size' as simd-width.<br></div><div>Like AMDGPU, the arch support scalar/vector register. the vector width is 16 if the simd-width/warp-size is 16. <br></div><div>But the scalar/vector register reside in only one register file, so they need to alias each other. That is a vector register can also be used as several scalar registers.<br></div><div>What I choose to do is define scalar 'short' type register, and a vector register for QWord is composed of 16(simd-width)*4(size in unit of short) = 64 uniform short register.<br></div><div>So, for normal usage under simd-width of 16, 64bit lane mask is enough.<br></div><div><br>The problem is the 'store' or 'load' operation can support up to SIMD16 of 4 DWord read/write. And the arch requires the four element register in consecutive registers.<br>So I have to define a
registerTuple that is composed of 16(simd-width) * 4(element) * 2(size in
units of short) = 128 uniform short register. That means 128 bits
lanemask.<br></div><br></div></div></div></div></div><div><div><div><div>Some previous discussion threads if you are interested:<br><a href="http://lists.llvm.org/pipermail/llvm-dev/2016-August/103953.html">http://lists.llvm.org/pipermail/llvm-dev/2016-August/103953.html</a><br><a href="http://lists.llvm.org/pipermail/llvm-dev/2016-September/104772.html">http://lists.llvm.org/pipermail/llvm-dev/2016-September/104772.html</a><br><br></div><div>Thanks!<br></div><div>Ruiling<br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-10 23:20 GMT+08:00 Krzysztof Parzyszek via llvm-dev <span dir="ltr"><<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Would uint64_t be sufficient for you?<br>
<br>
-Krzysztof<span class="gmail-"><br>
<br>
On 10/9/2016 12:39 AM, Ruiling Song via llvm-dev wrote:<br>
</span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
Hello Alex,<br>
<br>
I am very interested in your change to support more than 32bit lanemask.<br>
I am working on a new llvm backend target which may also needs such kind<br>
of support.<br>
I am not sure whether it is convenient to share the change with me? So I<br>
could have some try.<br>
<br>
Thanks!<br>
Ruiling<br>
<br>
2016-09-19 5:14 GMT+08:00 Alex Susu via llvm-dev<br></span>
<<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> <mailto:<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.or<wbr>g</a>>>:<span class="gmail-"><br>
<br>
Hello.<br>
I've managed to patch the various files from the back end<br>
related to lanemask - now I have 1024-bit long lanemask.<br>
But now I get the following error when giving make llc:<br>
<<error:unhandled vector type width in intrinsic!>><br>
This error comes from this file<br>
<a target="_blank" rel="noreferrer" href="https://github.com/llvm-mirror/llvm/blob/master/utils/TableGen/IntrinsicEmitter.cpp">https://github.com/llvm-mirror<wbr>/llvm/blob/master/utils/TableG<wbr>en/IntrinsicEmitter.cpp</a><br></span>
<<a target="_blank" rel="noreferrer" href="https://github.com/llvm-mirror/llvm/blob/master/utils/TableGen/IntrinsicEmitter.cpp">https://github.com/llvm-mirro<wbr>r/llvm/blob/master/utils/Table<wbr>Gen/IntrinsicEmitter.cpp</a>>,<span class="gmail-"><br>
comes from the fact there is no IIT_V128 (nor IIT_V256), and they is<br>
a switch case using them in method static void<br>
EncodeFixedType(Record *R, std::vector<unsigned char> &ArgCodes,<br>
std::vector<unsigned char> &Sig).<br>
<br>
Is there any reason these enum IIT_Info ( IIT_V128, IIT_V256)<br>
are not added in file /IntrinsicEmitter.cpp?<br>
<br>
Thank you,<br>
Alex<br>
<br>
<br>
On Tue, Sep 13, 2016 at 1:47 AM, Matthias Braun <<a target="_blank" href="mailto:mbraun@apple.com">mbraun@apple.com</a><br></span>
<mailto:<a target="_blank" href="mailto:mbraun@apple.com">mbraun@apple.com</a>>> wrote:<div><div class="gmail-h5"><br>
<br>
<br>
> On Sep 8, 2016, at 6:37 AM, Alex Susu via llvm-dev <<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> <mailto:<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.or<wbr>g</a>>> wrote:<br>
><br>
> Hello.<br>
> In my TableGen back end description I need to use more than 32 (e.g., 128, 1024, etc) subregisters per register for my research SIMD processor. I have used so far with success 32 subregisters.<br>
><br>
> However, when using 128 subregisters when I now give the command:<br>
> llvm-tblgen -gen-register-info Connex.td<br>
> I get an error message "error:Ran out of lanemask bits to represent subregister sub_16_033".<br>
><br>
> To handle this limitation, I started editing the files where this error comes from:<br>
> llvm/utils/TableGen/CodeGenReg<wbr>isters.h<br>
> llvm/utils/TableGen/CodeGenReg<wbr>isters.cpp<br>
> More exactly, the error comes from the fact the member LaneMask of the classes CodeGenSubRegIndex and CodeGenRegister is unsigned (i.e., 32 bits). So for every lane/subregister we require a bit from the type LaneMask.<br>
> I plan to use type long (or even type int1024_t from the boost library, header cpp_int.hpp) for LaneMask and change accordingly the methods handing the type.<br>
><br>
> Is there are any limitation I am not aware of (maybe in LLVMV's register allocator) that would prevent me from using more than 32 lanes/subregisters?<br>
<br>
There is no known limitation. I chose uint32_t out of concern<br>
for compiletime. Going up for uint64_t should be no problem, I'd<br>
be more concerned about bigger types; hopefully all code<br>
properly uses the LaneBitmask type instead of plain unsigned,<br>
you may need a few fixes in that area.<br>
(For history: We had a scheme in the past where the liveness<br>
tracking mapped all lanes after lane 31 to the bit 32, however<br>
that turned out to need special code in some places that turned<br>
out to be a constant source of bugs that typically only happened<br>
in big and hard to debug inputs so we moved away from this scheme).<br>
<br>
- Matthias<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br></div></div>
<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> <mailto:<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.or<wbr>g</a>><br>
<a target="_blank" rel="noreferrer" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<<a target="_blank" rel="noreferrer" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/llvm-dev</a>><span class="gmail-"><br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a target="_blank" rel="noreferrer" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</span></blockquote><span class="gmail-HOEnZb"><font color="#888888">
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a target="_blank" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a target="_blank" rel="noreferrer" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>