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

Krzysztof Parzyszek via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 19 15:04:12 PDT 2017


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>. 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>> 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>>> 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


More information about the llvm-dev mailing list