similar to: [LLVMdev] Trunc Load

Hi Johannes, what processor are you targeting? Is it little-endian or big-endian? Ciao, Duncan. > I have the following simple IR: > > ================================== > @l = common global i64 0, align 8 > > define void @hello() nounwind { > entry: > store i64 -4919131755279862989, i64* @l > ret void > } > > define i32 @main(i32 %argc, i8** %argv)

> Hi Johannes, what processor are you targeting? Is it little-endian or > big-endian? Little-endian. (The truth: you can set it manually, but it is set to little endian, for sure.) The processor is a TI TMS320C64x. Follow-up: I discovered that the "guilty" method is DAGCombiner::ReduceLoadWidth. The error is introduced because the offset is not calculated correctly. The first

On Thu, Oct 27, 2011 at 9:29 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: > >> Hi Johannes, what processor are you targeting?  Is it little-endian or >> big-endian? > Little-endian. (The truth: you can set it manually, but it is set to > little endian, for sure.) The processor is a TI TMS320C64x. > > Follow-up: I discovered that the

> This is contradictory: on a little-endian processor, the address for > loading a 64-bit value is same as the address of the low word. Are > you sure you're modeling the semantics of your lddw and stddw > instructions correctly? ... I thought so until now. Because I implemented stdw (store doubleword) completely analogous to lddw: Just print out stdw with the given pointer and

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 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > 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()); >

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 am trying to prototype a back end for a new processor. It has a 64-bit datapath, so all registers are 64 bits and load instructions always extend to 64 bits. But the type 'int' is 32 bits, and arithmetic instructions have variants that operate on only the lower 32 bits of each register. So for a basic 'a = b + c' example, we get %0 = load i32, i32* @b, align 4, !tbaa !1 %1

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))]>, >>

Christian Sayer wrote: > Hi, > my target architecture has a kind of "16bit addressing mode", i.e. one address does not address 8 bit but a 16bit chunk. Consequently, every constant used to calculate effective addresses must be divided by two. > So far this is not such a problem for stack objects since FrameIndexes, function arguments etc. have a lot of custom lowering code where

Hello, I'm getting a machine verifier error after introducing the earlyclobber constraint to some instructions where the src and dest regs can't be the same. The offending instruction pattern is this one: let canFoldAsLoad = 1, isReMaterializable = 1, Constraints = "@earlyclobber $dst" in def LDDWRdPtrQ : Inst<(outs DREGS:$dst), (ins memri:$src),

Hi All, My target has 32bit registers, but it has some 64bit instructions which are using pairs of these 32bit registers. I have defined registers, aliases and subregister set. The problem is that register allocator is using 32bit registers that are already used in a pair, for example: lw $r0, 16[$r12] // load word to r0 ld $p0, 36[$r12] // load doubleword to p0 shl $p0, $p0, $r0 // shift

On Jul 14, 2012, at 10:09 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello, > > I'm getting a machine verifier error after introducing the earlyclobber constraint to some instructions where the src and dest regs can't be the same. The offending instruction pattern is this one: > > let canFoldAsLoad = 1, > isReMaterializable = 1, > Constraints =

The parts of klibc specific to the parisc architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 078d6614054391efe17093f8d70340e2c0644ffb tree 63a4bf899e5ca2ef3c0a8e9ef3098273012f7a33 parent ebd2860ad3dc19cb11fd5b9cc235cab54e9165f4 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:36 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

From: Maros Zatko <mzatko@redhat.com> --- fish/test/Makefile.am | 39 ++++++++++++++++ fish/test/testquoting.c | 120 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 159 insertions(+) create mode 100644 fish/test/Makefile.am create mode 100644 fish/test/testquoting.c diff --git a/fish/test/Makefile.am b/fish/test/Makefile.am new file mode 100644 index

Hello Jakob, I'm still getting the error, I can give you any other debug info you need. I haven't pasted the regalloc debug info here because it is quite huge, but if you tell me what specific details you need I will include them. Thanks for your help! 2012/7/14 Jakob Stoklund Olesen <stoklund at 2pi.dk> > > On Jul 14, 2012, at 10:09 AM, Borja Ferrer <borja.ferav at

Hello, Artur > I have defined registers, aliases and subregister set. > The problem is that register allocator is using 32bit registers that are > already used in a pair, for example: > lw $r0, 16[$r12]   // load word to r0 > ld $p0, 36[$r12]   // load doubleword to p0 > shl $p0, $p0, $r0    // shift left p0 by r0  and store result in p0 > where p0 is a pair r0:r1 > Could

Hello, I've noticed the following issue while testing some codegen tests, i would like to know if it's a missed optimization or i missed something out here. This is for an out of tree backend im writing. I managed to reduce it to the following C function: void foo(int *a) // int here is 16bits { *a &= 0xFF; } This is the code before regalloc: Live Ins: %R25R24

From: Maros Zatko <hacxman@gmail.com> Auxiliary functions for readline to support space character escaping in filenames in future. Escaping function is taken from fish.c (used to be parse_quoted_string) plus its un-escaping counterpart. There are a few tests for both. Maros Zatko (3): fish: rl.{c,h} - escaping functions for readline fish: basic tests for readline escaping autotools:

Nadav, The problem appears only for vectors longer than available hardware register (in doubleword elements, i.e. more than 4 on SSE4 and more than 8 on AVX). Select does weird thing. <8 x i1> mask comes as two XMM registers, select converts them to a single XMM registers (i.e. 8 x 16 bit), immediately after it converts back to two XMM registers and does blend. Conversion forth and back has