similar to: 16-bit bytes for AsmPrinter/DWARF

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

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:

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

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

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

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

Hi all, The AsmPrinter class supports functions like EmitInt8, EmitInt16, and EmitInt32 for writing a 1/2/4 byte directive to the assembly. Each of these calls the MCStreamer::EmitIntValue method with the corresponding size. For some reason, there is no EmitInt64, and I was wondering if there was a fundamental reason why? The EmitIntValue function appears to support 8-byte inputs. I dug into

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>

DWARF already needs to emit 64-bit values, being the type-unit hashes. How is that being done? (If it's going directly to the streamer, then we're already assuming all assemblers are okay with what the streamer does, and adding an AsmPrinter helper seems very reasonable.) --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Henderson via llvm-dev Sent:

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

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?

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

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

Thank you, Clayton. It works now! Our debugger server responds "name:J28;generic:fp;bitsize:32;encoding:uint;format:hex;gcc:60;dwarf:60". And I also set other "generic" attributes like sp, pc, ra, arg1~arg8 to related registers. I dig a little and find llvm dwarf generator uses TargetRegisterInfo::getFrameRegister() to obtain frame base, and uses

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude

Hi Dean, I have a question for 32-bit platforms. I see in the code that you used the following in compiler-rt/trunk/lib/xray/xray_interface_internal.h : struct XRaySledEntry { uint64_t Address; uint64_t Function; unsigned char Kind; unsigned char AlwaysInstrument; unsigned char Padding[14]; // Need 32 bytes }; And the peer code in llvm/trunk/lib/Target/X86/X86MCInstLower.cpp : void