similar to: RFC: On removing magic numbers assuming 8-bit bytes

On Thu, 2019-05-02 at 19:54 +0200, Pavel Šnobl wrote: > Hi Jesper, > > thank you for working on this. My company (Codasip) would definitely > be interested in having this feature upstream. I think that this is > actually important for a suprisingly large number of people who > currently have to maintain their changes downstream. I have a couple > of questions and comments:

Hi, I'm with a team using 16-bit bytes for an out-of-tree target. The AsmPrinter framework's implementation of the DWARF debugging format is not very good at distinguishing between target-sized bytes (which is the more common use) and 8-bit-bytes. The DWARF standard itself seems not very good in this regard, actually. So we have had to hack our way around this. I.e., at some call-sites of

Hi Jeroen, Thanks, these are interesting differences. The CHAR_BIT and byte relation is established in the C standard and I would prefer the byte terminology. It means the same thing as addressable unit but is a bit shorter and probably more widely known. Do you suggest any in-tree changes at some call sites using the suggested AdressSpace parameter or would we rely on the default value always?

This RFC is to ask whether the community is interested in further discussion of iN bytes support. Last time the issue was on the agenda in May and the discussion was triggered by Jesper Antonsson's patches (see <https://lists.llvm.org/pipermail/llvm-dev/2019-May/132080.html> https://lists.llvm.org/pipermail/llvm-dev/2019-May/132080.html). It seems that, while some downstream areas

On Fri, 2019-08-30 at 10:03 -0700, Quentin Colombet wrote: > > On Aug 30, 2019, at 8:31 AM, Jesper Antonsson via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > After dead-mi-elimination I'm experiencing a machine verifier > > failure > > at this virtual subregister write: > > > > %5.sub1 = COPY undef

On Wed, 2019-05-08 at 11:12 -0700, Philip Reames wrote: > On 5/8/19 1:25 AM, Jesper Antonsson wrote: > > On Mon, 2019-05-06 at 15:56 -0700, Philip Reames via llvm-dev > > wrote: > > > On 5/6/19 2:43 AM, Tim Northover via llvm-dev wrote: > > > > On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev > > > > <llvm-dev at lists.llvm.org>

*From: *JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> *Date: *Thu, May 9, 2019 at 1:30 PM *To: *Jesper Antonsson *Cc: *dag at cray.com, llvm-dev at lists.llvm.org I don’t think you have consensus to move forward at this point in time. My > expectation, which I think represents LLVM’s historical approach, is that a > path to full support be planned out before this effort starts.

I agree that consensus seems to be missing. There's definitely some assumptions, and more in particular, API and usage assumptions around 8 bit bytes in the backends. Also: How do you plan on keeping these assumptions from creeping back in? -eric On Thu, May 9, 2019 at 10:30 AM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On May 9, 2019, at 5:29 AM,

On Mon, 2019-05-06 at 15:56 -0700, Philip Reames via llvm-dev wrote: > > > On 5/6/19 2:43 AM, Tim Northover via llvm-dev wrote: > > On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > Although the above is mentioning bytes, looking at the "/ > > > 8" and "& 0x7" makes

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF > Bastien via llvm-dev > > I’m not a fan of C and C++ supporting anything but 8 bits per byte. > Realistically, C and C++ on such targets are different languages from 8- > bit-per-byte C and C++, and therefore code isn’t portable from one to the > other. Having done

Hi, After dead-mi-elimination I'm experiencing a machine verifier failure at this virtual subregister write: %5.sub1 = COPY undef %11 The machine verifier essentially complains that the rest of the register is undefined (a subregister write implies a "read" of the other parts). So the problem is that dead-mi-elimination has removed the previously existing defines of %5.sub0.

Hi, I'm a bit unsure of the semantics of undef physical registers. The explanations I've seen in the code and in the langref seems to pertain more to constant values and virtual registers. What I really want to achieve is a push-pop of a register to have a temporary to work with, without having to check if this register is defined or not. However, whenever the reg is not defined before

> On Nov 1, 2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > A summary of the discussion so far. > > It seems that there are two possible solutions on how to move forward with non 8 bits byte: > > 1. Commit changes without tests. Chris Lattner, Mikael Holmen, Jeroen Dobbelaere, Jesper Antonsson support this idea. > James Y

On Wed, 2019-10-30 at 15:30 -0700, Chris Lattner via llvm-dev wrote: > > On Oct 30, 2019, at 3:07 AM, Jeroen Dobbelaere via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of JF > > > Bastien via > > > > [..] > > > Is it relevant to any modern compiler

I agree, addressable unit size is probably a better abstraction. However, in the lib/CodeGen directory alone, there's some 785 uses of the word "byte" and a significant fraction of the code that we want to modify is using the byte terminology today. An example of unmodified code from my showcase patch set: assert(!(Shift & 0x7) == 0 && "Shifts not

On Sat, Nov 2, 2019 at 12:45 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Nov 1, 2019 at 8:40 AM Adrian Prantl via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > On Nov 1, 2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > It seems that there are two possible

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

On Mon, Nov 4, 2019 at 4:00 PM James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > To throw my hat into the ring, we also maintain a downstream target that > has a subset of this problem - it has non-8-bit-addressable memory. This > means that %uglygeps don't work, pointers can't be casted to i8* and expect > to be byte-addressed (conversions to

The early bird rate for registration <https://www.eventbrite.com/e/eurollvm19-developers-meeting-brussels-belgium-tickets-53016346319> will end on Feb 26th, 2019 which means you have less than 8 hours to lock in the lower rate. Ticket prices will increase on Feb 26th at 12:01AM PST. Thanks, Tanya -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Simon, The page will be updated later today with the new rate. Kind regards, Arnaud On Tue, Feb 26, 2019 at 12:52 PM Simon Dardis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > The EventBrite page is showing sales have ended, will it be reopening with > the higher rate soon? > > Thanks, > Simon > > On Tue, 26 Feb 2019 at 00:20, Tanya Lattner via