search for: promoteintegers

...ively. They would be useful for any backend that doesn't want to implement varargs or by-value calling conventions. * Instruction-level lowering: * ExpandStructRegs splits up struct values into scalars, removing the "insertvalue" and "extractvalue" instructions. * PromoteIntegers legalizes integer types (e.g. i30 is converted to i32). * Module-level lowering: This implements, at the IR level, functionality that is traditionally provided by "ld". e.g. ExpandCtors lowers llvm.global_ctors to the __init_array_start and __init_array_end symbols that are used by C...

On Feb 2, 2009, at 1:51 PM, Eli Friedman wrote: > 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

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

Hi Eli, Recently, I proposed some changes to LLVM to do more lowering of illegal types (like i128 or i17) and other things within the LLVM IR layer, and the proposal was roundly rejected by the LLVM community: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061567.html PNaCl is essentially doing what my proposal described. How do you expect to reconcile the community's desire to avoid

...useful for any backend that doesn't want to >>>> implement varargs or by-value calling conventions. >>> >>> Why wouldn't these be applicable to existing backends? What is >>> hard about the existing representations? And this... >>>>    * PromoteIntegers legalizes integer types (e.g. i30 is >>>> converted to i32). >>> >>> Does it split up too-wide integers? Do we really want another >>> integer legalization framework in LLVM? I am actually interested >>> in doing (partial) legalization in the IR durin...

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

...>> "insertvalue" and "extractvalue" instructions. >> > > There are already passes that do this outside of function arguments and > return values. Why is a new one needed? How do you handle the > overflow-detecting operations? > > > >> * PromoteIntegers legalizes integer types (e.g. i30 is converted to >> i32). >> > > Does it split up too-wide integers? Do we really want another integer > legalization framework in LLVM? I am actually interested in doing (partial) > legalization in the IR during lowering (codegenprep time) i...

Hello, Following an earlier email ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063010.html), we've published an initial version of the PNaCl bitcode reference manual online - http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl bitcode is a restricted subset of LLVM IR. The reference manual is quite terse, so for the bigger picture I'll repost links to the design

Current dragonegg svn has all of the -fplugin-arg-dragonegg-enable-gcc-optzns bugs for usage with -ffast-math -O3 addressed except for those related to PR2314. Using the -fno-tree-vectorize option, we can evaluate the current state of -fplugin-arg-dragonegg-enable-gcc-optzns with the Polyhedron 2005 benchmarks compared to stock dragonegg and stock gcc 4.5.4. The runtime benchmarks below show that