similar to: How exactly is datatype alignment determined?

On Mon, 22 May 2017, Krzysztof Parzyszek via llvm-dev wrote: > Probably from LargeArrayMinWidth/LargeArrayAlign settings in Targets.cpp (in > clang). Wait what? In clang? But my input is already LLVM IR. MF->getDataLayout().getPrefTypeAlignment(Ty) must be basing its answer on either something in the IR file, or in the target implementation, but clang is not really in the picture.

On Mon, 22 May 2017, Dr. ERDI Gergo wrote: > Actually, tracking down the sequence of function calls, it turns out that '8' > is ultimately coming from the following call in DataLayout::getAlignment: > > getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); > > this seems to return 8 with the following datalayout string: > >

The 8 in the data layout string should have been converted to a byte value by this code before it was passed to setAlignment. As far as I cant ell getAlignment should return the byte alignment that was passed to setAlignment, not the bit alignment from the string. // ABI alignment. if (Rest.empty()) report_fatal_error( "Missing alignment specification in

> Are you looking in Clang's source, and that from the same 7.0 version? Yes, I am, and it’s the same version (7.0.1). “LargeArrayMinWidth” is only on the following files: TargetInfo.cpp TargetInfo.h So I still think there’s something else that makes the difference on the x86 target. Anyway, I will now investigate other targets as my temporary frontend. It is right that other targets

I am working on a custom LLVM backend for a 16 bit architecture. For my architecture, I need smaller array alignments for arrays created on the stack. For example, consider the following code at the start of a C function: char localBuff[20]; char localBuff2[6]; this gets converted by Clang into this: %localBuff = alloca [20 x i8], align 16 %localBuff2 = alloca [6 x i8], align 1 Note

Hi, While working on the AVR target, I noticed a problem with alignment and the various atomic operations. AVR is an 8-bit platform, and all data is unaligned (or 8-bit aligned if you will). Here's a small piece of LLVM IR exhibiting this (emitted by the Rust compiler): target datalayout = "e-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8" target triple =

On Tue, 9 May 2017, Krzysztof Parzyszek wrote: > def: Pat<(ld (add (WRAPPER RC:$addr), (sign_extend RC:$offset))), > (load_instruction_rr RC:$addr, RC:$offset)>; > > Where "load_instruction" is a machine load instruction with base address and > an offset, both in registers, and RC is the corresponding register class. Can I also use something more complex

On Tue, 30 May 2017, Nemanja Ivanovic wrote: > This is typically accomplished with something like PPC's `RegConstraint` and > `NoEncode`. You can see examples of it that are very similar to what you're after in > PPC's load/store with update forms (i.e. load a value and update the base register > with the effective address - these are used for pre-increment loads/stores).

The reason the ones in PPCInstrInfo.td don't have the patterns to match is the reason they are more analogous to your problem. Namely, tblgen does not have a way to produce nodes with more than one result. The load-with-update instructions do exactly that - one of the inputs is also an output, but the other output is independent (and necessarily a separate register). The FMA variants have

Hi, I've been looking at the new AVR backend lately, and one issue I've found is that all 'load' IR instructions are matched using the 'ld' AVR instruction, including 'load's for lookup tables generated from switches. On the AVR architecture, RAM and the program image are in completely separated namespaces. There's a distinct 'lpm' (Load from Program

Hi Tim, I appreciate your reply, but I can’t still find any relation with “LargeArrayMinWidth” and x86 target. This variable is only in the TargetInfo.cpp and TargetInfo.h files and it’s not even in any x86 related file. I think there should be something else that causes my issue. I have my backend very advanced and already producing good assembly code, but this supposedly simple thing has got me

Hi, During instruction selection, I have the following code for certain LOAD instructions: const LoadSDNode *LD = cast<LoadSDNode>(N); SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions

On 07/09/12 18:13, Chris Lattner wrote: > On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow

Hi, I'd like to define a pseudo-instruction whose expansion will, as a side-effect, overwrite an input register's value: the pseudo-instruction ldw r1:r2, P to load 2 bytes from memory address P is to be expaneded to ld r1, P+ ld r2, P where "ld _, P+" is an instruction that loads a single byte from P, and post-increments P by one. How can I represent this behaviour in

I think I found it. In InstCombiner::ComputeMaskedBits we have the following lines: if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { unsigned Align = GV->getAlignment(); if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); It assumes that global

Hi Nicolas, > if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { > > unsigned Align = GV->getAlignment(); > > if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) > > Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); > > It assumes that global values are always optimally

Yes, I was just about to send out: DL->getABITypeAlignment(ScalarDataTy); The question is: “… ABI alignment for the target …" is that getPrefTypeAlignment or getABITypeAlignment I would have thought the latter. On Nov 15, 2013, at 4:12 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Arnold Schwaighofer"

On Mon, 8 May 2017, Krzysztof Parzyszek via llvm-dev wrote: > You can create the differentiation between objects in the data memory and in > the program memory in LowerGlobalAddress (e.g. you can create different ISD > opcodes that generate these addresses) and then use those to select > corresponding instructions. Right, which is how I also understand Zhai Xiang's suggestion

On Sun, 28 May 2017, David Chisnall wrote: >> let Constraints = "@earlyclobber $reg" in >> def LDWRdPtr : Pseudo<(outs DREGS:$reg), >> (ins PTRREGS:$ptrreg), >> "ldw\t$reg, $ptrreg", >> [(set i16:$reg, (load i16:$ptrreg))]>, >>

Hi Dmitry, > I'm attaching a patch that should fix the issue mentioned above. It > simply makes the same check seen in the same file for global > variables: > > emitPTXAddressSpace(PTy->getAddressSpace(), O); > if (GVar->getAlignment() == 0) > O << " .align " << (int) TD->getPrefTypeAlignment(ETy); > else > O