search for: antonsson

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

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

*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. Concretely, > I expec...

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

...so seen some community interest in those areas, e.g. from Embecosm: https://www.embecosm.com/2018/02/26/how-much-does-a-compiler-cost/ and from within Ericsson: https://www.youtube.com/watch?v=HAqtEZmci70 Thanks, Jesper > Thank you, > Pavel > > On Thu, May 2, 2019 at 2:20 PM Jesper Antonsson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > A. This RFC outlines a proposal regarding non-8-bit-byte support > > that > > got positive reception at a Round Table at EuroLLVM19. The > > general > > topic has been brought up several ti...

...r, 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, Jesper Antonsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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 Northove...

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

A. This RFC outlines a proposal regarding non-8-bit-byte support that got positive reception at a Round Table at EuroLLVM19. The general topic has been brought up several times before and one good overview can be found in a FOSDEM 2017 presentation by Jones and Cook: https://archive.fosdem.org/2017/schedule/event/llvm_16_bit/ In a nutshell, the proposal is for the llvm community

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.

...lvm-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 Knight says that at least magic numbers should be removed "at least where it arguably helps code clarity". This might be not exactly the scope of the changes discussed, but it's probably worth do discuss code clarity having concrete patches. > GCC (a...

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

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

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 benefit from non-8-bit bytes support, this feature is barely maintainable given the lack of utilizat...

...vm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > 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 Knight says that at least magic numbers should be removed "at >> least where it arguably helps code clarity". This might be not exactly the >> scope of the changes discussed, but it's probably worth do discuss code >> clarity...

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

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

...lvm.org> wrote: >>>> > 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 Knight says that at least magic numbers should be removed "at >>>> least where it arguably helps code clarity". This might be not exactly the >>>> scope of the changes discussed, but it's probably worth do discus...

...d be implemented as : > unsigned getAddresssableUnitSize(unsigned AS=0) { return 8; } > > Greetings, > > Jeroen Dobbelaere > > > > -----Original Message----- > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of > > Jesper > > Antonsson via llvm-dev > > Sent: Thursday, May 2, 2019 14:21 > > To: llvm-dev at lists.llvm.org > > Subject: [llvm-dev] RFC: On removing magic numbers assuming 8-bit > > bytes > > > > A. This RFC outlines a proposal regarding non-8-bit-byte support > > that >...

Hi, We had a problem with AssertingValueHandles exploding in opt for certain sequences of passes and registered TR 27050<https://llvm.org/bugs/show_bug.cgi?id=27050> for this. No takers, so I decided to dig a bit deeper into it and found the cause: The CallGraph construction is run twice, and as the first instance is left lying around even after the point at which its analysis is determined

Hi, I work with an out-of-tree backend for a VLIW architecture and we use bundling extensively. We have opted to put DBG_VALUES inside bundles to keep them together with their originating instructions. However, as no (in-tree) backends do this to our knowledge, we have recently started to question if that's a wise approach. Several patches are needed to make bundled DBG_VALUEs work and since