search for: scanoperand

...his case the operand types need to be accounted for in this determination. Enhancing the logic there to consider the result types in this case seems like it should be straightforward, but how general a problem is this? [Can this problem only happen with vsetcc nodes?] Maybe, for example, after the ScanOperands part of DAGTypeLegalizer::run, if we need to reanalyze, we should actually run ScanOperands again instead of starting with the result-type processing? Thanks in advance, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

...the operand types need to be accounted for in this determination. Enhancing the logic there to consider the result types in this case seems like it should be straightforward, but how general a problem is this? [Can this problem only happen with vsetcc nodes?] > > Maybe, for example, after the ScanOperands part of DAGTypeLegalizer::run, if we need to reanalyze, we should actually run ScanOperands again instead of starting with the result-type processing? > > Thanks in advance, > Hal >

...at >> constructs a vector of i32 values that are then bitcast to the >> original vector type. > > I'm pretty sure the target-independent legalizer does no such thing. > Can you point to the code you're talking about? In DAGTypeLegalizer::run(), the loop after the "ScanOperands" label looks at the operands of the BUILD_VECTOR and the getTypeAction method returns PromoteInteger (because i8 and i16 are promoted to fit in 32- bit registers on PPC). > > > That said, I do recall the x86 backend does a similar > platform-specific transformation with cons...

On Mon, Feb 2, 2009 at 11:31 AM, Bob Wilson <bob.wilson at apple.com> wrote: > LLVM's type legalizer is changing the types of BUILD_VECTORs in a way > that seems wrong to me, but I'm not sure if this is a bug or if some > targets may be relying on it. > > On a 32-bit target, the default action for legalizing i8 and i16 types > is to promote them. This isn't

LLVM's type legalizer is changing the types of BUILD_VECTORs in a way that seems wrong to me, but I'm not sure if this is a bug or if some targets may be relying on it. On a 32-bit target, the default action for legalizing i8 and i16 types is to promote them. If you then have a BUILD_VECTOR to construct a legal vector type composed of i8 or i16 values, the type legalizer will