search for: bitsperbyte

...tore it as three 16-bit bytes, i.e. 48 bits. When storing a v4i40 vector it will be stored as 4x48 bits. One thing that we have had to patch is the getStoreSize() method in ValueTypes/MachineValueTypes where we assume that vectors are bitpacked when the element size is smaller than the byte size (“BitsPerByte”): /// Return the number of bytes overwritten by a store of the specified value /// type. unsigned getStoreSize() const { - return (getSizeInBits() + 7) / 8; + // We assume that vectors with elements smaller than the byte size are + // bitpacked. And that elements lar...

...; bits. > > When storing a v4i40 vector it will be stored as 4x48 bits. > > One thing that we have had to patch is the getStoreSize() method in > ValueTypes/MachineValueTypes where we assume that vectors are > bitpacked when the element size is smaller than the byte size > (“BitsPerByte”): > >      /// Return the number of bytes overwritten by a store of the > specified value > >      /// type. > >      unsigned getStoreSize() const { > > -      return (getSizeInBits() + 7) / 8; > > +      // We assume that vectors with elements smaller than the b...

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

...ew to LLVM dev, but I have been working with a target with a minimum addressable byte of 16-bits. I found that in DAGCombiner::visitAND, EVT::isRound could create i8 loads on my 16-bit target which are ultimately invalid. EVT::isRound appears to use a hard-coded 8, rather than pulling the targets BitsPerByte field. Is this a potential bug or is there a better way to address this? Hard coding a 16 in the isRound field fixes the issue for me. Cheers, Sam

...tore it as three 16-bit bytes, i.e. 48 bits. When storing a v4i40 vector it will be stored as 4x48 bits. One thing that we have had to patch is the getStoreSize() method in ValueTypes/MachineValueTypes where we assume that vectors are bitpacked when the element size is smaller than the byte size (“BitsPerByte”): /// Return the number of bytes overwritten by a store of the specified value /// type. unsigned getStoreSize() const { - return (getSizeInBits() + 7) / 8; + // We assume that vectors with elements smaller than the byte size are + // bitpacked. And that elements lar...

...I have been working with a target with a > minimum addressable byte of 16-bits. I found that in > DAGCombiner::visitAND, EVT::isRound could create i8 loads on my 16-bit > target which are ultimately invalid. EVT::isRound appears to use a > hard-coded 8, rather than pulling the targets BitsPerByte field. Is this > a potential bug or is there a better way to address this? Hard coding a > 16 in the isRound field fixes the issue for me. last time I checked LLVM did not have a BitsPerByte field. Are you working with a private copy of LLVM where someone has added support for non-octet b...

Thanks, Chris, for supporting the idea to have non-8-bits byte in LLVM. I want to clarify the scope and then analyze the options we have. The scope: 1. BitsPerByte or similar variable should be introduced to data layout; include/CodeGen/ValueTypes.h and some other generic headers also need to be updated and probably become dependent on the data layout. 2. Magic number 8 should be replaced with BitsPerByte. We found that 8 is used as "size of a byte in bi...

Hi Patrik, Thanks for this note. It's encouraging to read there has been some provision made for non-8-bit bytes. I'm not a compiler/backend expert, (although maybe I'll need to be soon!), so I won't look at the patches right now, however may at some stage in the future myself or colleague may request these patches from yourself. Yes, our 24-bit architectures have non-power-of-2

On 24/10/2019 14:21, JF Bastien via llvm-dev wrote: > I’d like to understand what programming model you see programmers using. > You don’t need 257 bits per byte if you only offer 257 bit integers. > Rather, bytes aren’t really a thing at that point. LLVM kinda handles iN > already, and your backend would legalize everything to exactly this type > and nothing else, right? Would