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

[hameeza ahmed via llvm-dev]

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>
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> 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>> 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>. 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>>> 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>>>> 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_sou
>>> rce=link&utm_campaign=sig-email&utm_content=emailclient>    Virus-free.
>>> www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_sou
>>> rce=link&utm_campaign=sig-email&utm_content=emailclient>
>>>
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170720/ec8556d7/attachment.html>