[llvm-dev] error:Ran out of lanemask bits to represent subregisterr

hameeza ahmed via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 20 08:36:17 PDT 2017


Hello, As craig said I managed to do it with the modifications in the 3
files. The modified files are attached here.

On Thu, Jul 20, 2017 at 5:49 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:

> So is everything working now?
>
> What changes exactly did you have to make?
>
> -Krzysztof
>
> On 7/20/2017 3:16 AM, hameeza ahmed wrote:
>
>> Thank you so much Craig
>> You are fantastic.
>> The problem is solved by your mentioned solutions.
>>
>> Thank you Krzysztof for your sincere help.
>>
>> Thanks alot
>>
>> On Thu, Jul 20, 2017 at 11:27 AM, hameeza ahmed <hahmed2305 at gmail.com
>> <mailto:hahmed2305 at gmail.com>> wrote:
>>
>>     Hello Krzysztof,
>>     The R_CASS definition is as follows:
>>
>>     class R_CASS<string n, bits<16> Enc,   list<Register> subregs = []>
>>     : Register<n> {
>>
>>     let Namespace = "X86";
>>     let HWEncoding = Enc;
>>        let SubRegs = subregs;
>>     }
>>
>>
>>
>>     On Thu, Jul 20, 2017 at 4:14 AM, Krzysztof Parzyszek
>>     <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote:
>>
>>         I tried reproducing the problem, but the file doesn't have
>>         everything I need (the class R_CLASS is not defined for example).
>>
>>         Craig's getLane patch fixes the shifts, but if you want to use a
>>         larger type than uint64_t, there is more work to do. I'll try to
>>         come up with something tomorrow.
>>
>>         -Krzysztof
>>
>>         On 7/19/2017 5:08 PM, hameeza ahmed wrote:
>>
>>             My code is attached here. I m trying to add in x86 for my
>>             target in this initial phase. Maybe later i will use
>>             separate target.
>>
>>             On Jul 19, 2017 10:04 PM, "Krzysztof Parzyszek"
>>             <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>
>>             <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>>> wrote:
>>
>>                  Could you share your .td file?
>>
>>                  Also, could you generate the .inc file by hand and show
>>             the output?
>>
>>                  You could use something like this to generate it:
>>                  llvm-tblgen -gen-register-info
>>             -I.../lib/Target/<your-target>
>>                  -I.../lib/Target -I.../include/llvm/Target
>>             <your-target>.td -o -
>>
>>                  What is the relationship of your target with X86?  Are
>>             you trying to
>>                  add something to it, or are you working on a separate
>>             target?
>>
>>                  -Krzysztof
>>
>>                  On 7/19/2017 4:47 PM, hameeza ahmed wrote:
>>
>>                      I have made changes in 3 files:
>>                      LaneBitmask.h, codegenregisters.cpp and
>>             miparser.cpp. files are
>>                      attached here.
>>
>>                      Now i am getting following errors. which means
>>             registerinfo.inc
>>                      file is not generated successfully.
>>
>>                                 /PIM/lib/Target/X86/MCTargetDesc/X86BaseInfo.h:733:24:
>> error:
>>                              no member named 'XMM8' in namespace
>> 'llvm::X86'
>>                            if ((RegNo >= X86::XMM8 && RegNo <=
>>             X86::XMM31) ||
>>
>>
>>                      fatal error: too many errors emitted, stopping now
>>             [-ferror-limit=]
>>                      20 errors generated.
>>
>>                      When i comment out the line to construct 65536 bit
>>             register in
>>             registerinfo.td <http://registerinfo.td>
>>             <http://registerinfo.td>
>>                      <http://registerinfo.td>. it run fine.
>>
>>                      What to do?
>>
>>                      On Thu, Jul 20, 2017 at 2:36 AM, Krzysztof Parzyszek
>>                      <kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>
>>             <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>>
>>                      <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>
>>                      <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>>>> wrote:
>>
>>                           Those couldn't be done generically, that's why
>>             the asserts
>>                      were added.
>>
>>                           -Krzysztof
>>
>>                           On 7/19/2017 4:30 PM, Craig Topper wrote:
>>
>>                               What about the static asserts protecting a
>>             Log call and
>>                      another
>>                               in the parser?
>>
>>                               On Wed, Jul 19, 2017 at 2:26 PM Krzysztof
>>             Parzyszek
>>                               <kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>
>>                      <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>>
>>             <mailto:kparzysz at codeaurora.org <mailto:
>> kparzysz at codeaurora.org>
>>                      <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>>>
>>                               <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>
>>                      <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>>
>>                               <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>
>>                      <mailto:kparzysz at codeaurora.org
>>             <mailto:kparzysz at codeaurora.org>>>>> wrote:
>>
>>                                    On 7/19/2017 4:18 PM, Craig Topper
>> wrote:
>>                                     > LaneMask isn't as self contained
>>             as it should
>>                      be. 64
>>                               bits is enough
>>                                     > here. The problem is accidental
>>             leaking of the
>>                      current size.
>>                                     >
>>                                     > For example there was a hard coded
>>             compare with
>>                      32 in
>>                               tablegen
>>                                    until I
>>                                     > fixed it recently.
>>
>>                                    This is most likely the only
>>             example.  I actually
>>                      tested it
>>                               with
>>                                    uint64_t (but without exceeding 32
>>             lanes).
>>
>>                                    -Krzysztof
>>
>>                                    --
>>                                    Qualcomm Innovation Center, Inc. is a
>>             member of
>>                      Code Aurora
>>                               Forum,
>>                                    hosted by The Linux Foundation
>>
>>                               --         ~Craig
>>
>>
>>                           --     Qualcomm Innovation Center, Inc. is a
>>             member of Code
>>                      Aurora Forum,
>>                           hosted by The Linux Foundation
>>
>>
>>
>>                  --     Qualcomm Innovation Center, Inc. is a member of
>>             Code Aurora Forum,
>>                  hosted by The Linux Foundation
>>
>>
>>             <http://www.avg.com/email-signature?utm_medium=email&utm_
>> source=link&utm_campaign=sig-email&utm_content=emailclient
>>             <http://www.avg.com/email-signature?utm_medium=email&utm_
>> source=link&utm_campaign=sig-email&utm_content=emailclient>>
>>     Virus-free. www.avg.com <http://www.avg.com>
>>             <http://www.avg.com/email-signature?utm_medium=email&utm_
>> source=link&utm_campaign=sig-email&utm_content=emailclient
>>             <http://www.avg.com/email-signature?utm_medium=email&utm_
>> source=link&utm_campaign=sig-email&utm_content=emailclient>>
>>
>>
>>             <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>>
>>
>>
>>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/d3b0b89e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CodeGenRegisters.cpp
Type: text/x-c++src
Size: 82095 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/d3b0b89e/attachment-0002.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LaneBitmask.h
Type: text/x-chdr
Size: 3069 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/d3b0b89e/attachment-0001.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MIParser.cpp
Type: text/x-c++src
Size: 76297 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/d3b0b89e/attachment-0003.cpp>


More information about the llvm-dev mailing list