similar to: [LLVMdev] Divergent stores to same location

On Wed, Mar 4, 2015 at 11:43 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ahmed, > > Yes, we do not have an 8 bit type and do not support 8 bit loads/extloads. > > For your first post, I imagine that anything that the DAGCombiner does it > could undo EXCEPT deciding to opt to a type that is not allowed, No, I think the SelectionDAG legalization should be able to

Curious, is there a pass/mechanism that exists to promote an instruction that is a value of a PHI? For example, if one of the incoming values is a sub(x, y) from BB2, does there exist something to promote this instruction back to BB2 (such that tmp = sub(x,y)) and the PHI replaces the sub instr with tmp? Or is the above the natural state that is then optimized into using sub, is there a call

On Thu, Sep 20, 2012 at 3:18 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Curious, is there a pass/mechanism that exists to promote an instruction > that is a value of a PHI? > > For example, if one of the incoming values is a sub(x, y) from BB2, does > there exist something to promote this instruction back to BB2 (such that tmp > = sub(x,y)) and the PHI replaces the

On Wed, Aug 15, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > So there are some #define (defined outside the function scope) that use > it_tab that are used inside the function, is this why it is promoting it to > a global? Macros shouldn't matter. Please give a complete testcase and steps to reproduce. And please don't top-post. -Eli > > On Wed,

So there are some #define (defined outside the function scope) that use it_tab that are used inside the function, is this why it is promoting it to a global? On Wed, Aug 15, 2012 at 2:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > #define r10(p,q,r,s) 0x##s##r##q##p > #undef r > #define r r10 > const word it_tab[4][256] = { r(const, const, const, const), >

On Wed, Aug 15, 2012 at 4:10 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Wed, Aug 15, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > So there are some #define (defined outside the function scope) that use > > it_tab that are used inside the function, is this why it is promoting it > to > > a global? > > Macros shouldn't

Hey Ryan, You end with a large constant immediate offset value because the register operand stores the register id in a union together with the offset that's used by the global address operand. Just add 'setOffset(0)' to your change method and that should solve your problem. 2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > So I have this for

I'm not sure I understand what your problem is, but are you calling the removeRegOperandFromUseList on the machine operand after changing it to GA? You have to call removeRegOperandFromUseList before changing the operand's type, as it expects a register operand. 2015-06-16 10:05 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > @Alex: Thanks. setOffset(0) eliminated any previous

Dear list, >From an earlier post I got the impression that one could promote warnings from a glm to errors (presumably by putting options(warn=1)?), then try() would flag them as errors. I?ve spent half the day trying to do this, but no luck. Do you have an explicit solution? My problems is that I am trying to figure out during what conditions one may find 5 significant parameters in a

> On Jun 15, 2015, at 7:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > To be more specific: > > We have some operators that we are currently implementing as intrinsics, for example things like: abs, min, max, etc..... > > for some code: > > int a; > > int food() > { > return abs(a); > } > > the corresponding operator should

#define r10(p,q,r,s) 0x##s##r##q##p #undef r #define r r10 const word it_tab[4][256] = { r(const, const, const, const), r(.......), r(.......) ....... }; All of this is done inside the function I want the alloc in. The variable is not declared/defined/used anywhere else. On Wed, Aug 15, 2012 at 12:00 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Wed, Aug 15, 2012

On Wed, Mar 4, 2015 at 10:49 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> Yes, it is breaking during the legalize phase, depending on which >> TargetLowering callback method we use. For example, Custom will let it >> through to instructions selection, which it breaks at the

Hi, In PromoteIntOp_STORE, why can we not promote a value and generate a truncating store if the incoming store is a truncating store? Naively, I can't see why we can promote the incoming value to a legal type and then generate a truncating store. For example, one has incoming code that produces an i16 via some operation and does a truncating store the result of that value in i8.

There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <http://reviews.llvm.org/D6946> - Matthias > On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> The DAG combiner also performs the undefined shift -> undef though, so it >> should still be OK > > DAG combiner doesn't really run to

AddRegisterOperand calls getVR and yes, I think an IMPLICIT_DEF is being generated. On Tue, Aug 25, 2015 at 2:40 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > On Aug 25, 2015, at 11:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I have not tried 3.5, it's a significant amount of work to port from one > version to the next though, I did not

1. MOV16Copy_IMM_REG is the instruction matched, sorry. AD is the multiclass. The IMM in my case is a global. So you can see that GPRBaseRegs, GPRBaseRegs sets the registerclass for both the src and dst operands, in this case (MOV16Copy_IMM_REG) it's the dst. 2. Yes I agree, it most likely would. Honestly, this comes across like a bug, or unintended feature. It's adding an extra COPY to

I have not tried 3.5, it's a significant amount of work to port from one version to the next though, I did not personally do the 3.4 to 3.6 porting. I agree though, it was very strange that it suddenly just changed behavior. It looks like to me that InstrEmitter.cpp:getVR is the one assigning the virtual register no? Though this code in CreateVirtualRegisters: const TargetRegisterClass *RC

Does a transform exist to breakdown the GEP? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111206/e88dddfe/attachment.html>

BB#0: derived from LLVM BB %entry %vreg0<def> = MOV16Copy_IMM_REG <ga:@a+1>[TF=1]; GPRRegs:%vreg0 %vreg1<def> = COPY %vreg0; PTRRegs:%vreg1 GPRRegs:%vreg0 Send_iii %NULLR0, %vreg1<kill>, 1, 1, 1, 1, 0; PTRRegs:%vreg1 RetRA This is what I get. This is what I'd like to get: BB#0: derived from LLVM BB %entry %vreg0<def> = MOV16Copy_IMM_REG

I would like it to always be lowered, I don't want it. On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com>wrote: > You don't have memcpy or want it to always lower it? > > -eric > > On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > Christoph, > > > > Yes, you are correct on the lifetime