Remove #uses comments from functions: they we're padded out to column 50
and were potentially confusing for externally visible functions.
going further, remove the "<i8**> [#uses=3]" comments entirely. They
add a lot of noise, confuse people about what the IR is, and don't add
any particular value. When the types are long it makes it really really
hard to read IR.
If someone is interested in this sort of thing, the right way to do this
is to implement an AsmAnnotationWriter that produces the same output, and
add a flag to llvm-dis (only) to produce this output.
llvm-svn: 112899
and were potentially confusing for externally visible functions.
going further, remove the "<i8**> [#uses=3]" comments entirely. They
add a lot of noise, confuse people about what the IR is, and don't add
any particular value. When the types are long it makes it really really
hard to read IR.
If someone is interested in this sort of thing, the right way to do this
is to implement an AsmAnnotationWriter that produces the same output, and
add a flag to llvm-dis (only) to produce this output.
llvm-svn: 112894
I wasn't able to convince myself that all GetMainExecutable
implementations always return absolute paths; this prevents
unexpected behavior in case they ever don't.
llvm-svn: 112888
large local stack areas or require dynamic stack realignment, allocate a
base register via which to access the local frame. This allows efficient
access to frame indices not accessible via the FP (either due to being out
of range or due to dynamic realignment) or the SP (due to variable sized
object allocation). In particular, this greatly improves efficiency of access
to spill slots in Thumb functions which contain VLAs.
rdar://7352504
rdar://8374540
rdar://8355680
llvm-svn: 112883
- Add patterns to match the following MMX builtins:
* __builtin_ia32_vec_init_v8qi
* __builtin_ia32_vec_init_v4hi
* __builtin_ia32_vec_init_v2si
* __builtin_ia32_vec_ext_v2si
These builtins do not correspond to a single MMX instruction. They will have
to be lowered -- most likely in the back-end.
llvm-svn: 112881
there are clearly no stores between the load and the store. This fixes
this miscompile reported as PR7833.
This breaks the test/CodeGen/X86/narrow_op-2.ll optimization, which is
safe, but awkward to prove safe. Move it to X86's README.txt.
llvm-svn: 112861
I'm sure it is harmless. Original commit message:
If PrototypeValue is erased in the middle of using the SSAUpdator
then the SSAUpdator may access freed memory. Instead, simply pass
in the type and name explicitly, which is all that was used anyway.
llvm-svn: 112810
Chris Lattner