These patterns are dead (because v4f32 stores are currently promoted to v4i32
and stored using Altivec instructions), and also are likely not correct
(because they'd store the vector elements in the opposite order from that
assumed by the rest of the Altivec code).
llvm-svn: 204839
These instructions have access to the complete VSX register file. In addition,
they "swap" the order of the elements so that element 0 (the scalar part) comes
first in memory and element 1 follows at a higher address.
llvm-svn: 204838
This patch is in similar vein to what done earlier to Module::globals/aliases
etc. It allows to iterate over function arguments like this:
for (Argument Arg : F.args()) {
...
}
llvm-svn: 204835
This commit fixes a cast instruction assertion failure
due to the incompatible type cast. This will only happen when
the target requires atomic libcalls.
llvm-svn: 204834
In some cases it is possible for CGP to attempt to reuse a base address from
another basic block. In those cases we have to be sure that all the address
math was either done at the same bit width, or that none of it overflowed
before it was extended.
Patch by Louis Gerbarg <lgg@apple.com>
rdar://16307442
llvm-svn: 204833
Add M_ZERO awareness to malloc() static analysis in Clang for FreeBSD,
NetBSD, and OpenBSD in a similar fashion to O_CREAT for open(2).
These systems have a three-argument malloc() in the kernel where the
third argument contains flags; the M_ZERO flag will zero-initialize the
allocated buffer.
This should reduce the number of false positives when running static
analysis on BSD kernels.
Additionally, add kmalloc() (Linux kernel malloc()) and treat __GFP_ZERO
like M_ZERO on Linux.
Future work involves a better method of checking for named flags without
hardcoding values.
Patch by Conrad Meyer, with minor modifications by me.
llvm-svn: 204832
Hopefully addresses r204539.
Make clang/test/lit.cfg pre-scan the RUN line looking for tool names,
and substitute fully qualified path names pointing to the build
directory. This ensures we're testing the just-built tools.
llvm-svn: 204831
> For functions where esi is used as base pointer, we would previously fall ba
> from lowering memcpy with "rep movs" because that clobbers esi.
>
> With this patch, we just store esi in another physical register, and restore
> it afterwards. This adds a little bit of register preassure, but the more
> efficient memcpy should be worth it.
>
> Differential Revision: http://llvm-reviews.chandlerc.com/D2968
This didn't work. I was ending up with code like this:
lea edi,[esi+38h]
mov ecx,0Fh
mov edx,esi
mov esi,ebx
rep movs dword ptr es:[edi],dword ptr [esi]
lea ecx,[esi+74h] <-- Ooops, we're now using esi before restoring it from edx.
add ebx,3Ch
mov esi,edx
I guess if we want to do this we need stronger glue or something, or doing the expansion
much later.
llvm-svn: 204829
v2i64 needs to be a legal VSX type because it is the SetCC result type from
v2f64 comparisons. We need to expand all non-arithmetic v2i64 operations.
This fixes the lowering for v2f64 VSELECT.
llvm-svn: 204828
This enables TableGen to generate an additional two operand matcher
for our ArithLogicR class of instructions (constituted by 3 register operands).
E.g.: and $1, $2 <=> and $1, $1, $2
llvm-svn: 204826
The interceptors had code that after macro expansion ended up looking like
extern "C" void memalign()
__attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
__attribute__((alias("memalign")));
That is,
* __interceptor_memalign is a function
* memalign is a weak alias to __interceptor_memalign
* __interceptor___libc_memalign is an alias to memalign
Both gcc and clang produce assembly that look like
__interceptor_memalign:
...
.weak memalign
memalign = __interceptor_memalign
.globl __interceptor___libc_memalign
__interceptor___libc_memalign = memalign
What it means in the end is that we have 3 symbols pointing to the
same position in the file, one of which is weak:
8: 0000000000000000 1 FUNC GLOBAL DEFAULT 1
__interceptor_memalign
9: 0000000000000000 1 FUNC WEAK DEFAULT 1 memalign
10: 0000000000000000 1 FUNC GLOBAL DEFAULT 1
__interceptor___libc_memalign
In particular, note that __interceptor___libc_memalign will always
point to __interceptor_memalign, even if we do link in a strong symbol
for memalign. In fact, the above code produces exactly the same binary
as
extern "C" void memalign()
__attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
__attribute__((alias("__interceptor_memalign")));
If nothing else, this patch makes it more obvious what is going on.
llvm-svn: 204823
The main difference between __va_start and __builtin_va_start is that
the address of the va_list has already been taken, and the va_list is
always a char*.
__va_end and __va_arg are not needed.
llvm-svn: 204821
parseDirectiveWord is a generic function that parses an expression which
means there's no need for it to have such an specific name. Renaming it to
parseDataDirective so that it can also be used to handle .dword directives[1].
[1]To be added in a follow up commit.
No functional changes.
llvm-svn: 204818
The '.set mips64' directive enables the feature Mips:FeatureMips64
from assembly. Note that it doesn't modify the ELF header as opposed
to the use of -mips64 from the command-line. The reason for this
is that we want to be as compatible as possible with existing assemblers
like GAS.
llvm-svn: 204817
The '.set mips64r2' directive enables the feature Mips:FeatureMips64r2
from assembly. Note that it doesn't modify the ELF header as opposed
to the use of -mips64r2 from the command-line. The reason for this
is that we want to be as compatible as possible with existing assemblers
like GAS.
llvm-svn: 204815
We've already got versions without the barriers, so this just adds IR-level
support for generating the new v8 ones.
rdar://problem/16227836
llvm-svn: 204813
Given that we support multiple directives that enable a particular feature
(e.g. '.set mips16'), it's best to hoist that code into a new function
so that we don't repeat the same pattern w.r.t parsing and handling error cases.
No functional changes.
llvm-svn: 204811
After some discussion on IRC, emitting a call to the library function seems
like a better default, since it will move from a compiler internal error to
a linker error, that the user can work around until LLVM is fixed.
I'm also adding a note on the responsibility of the user to confirm that
the cache was cleared on platforms where nothing is done.
llvm-svn: 204806
The directive '.option pic2' enables PIC from assembly source.
At the moment none of the macros/directives check the PIC bit
but that's going to be fixed relatively soon. For example, the
expansion of macros like 'la' depend on the relocation model.
llvm-svn: 204803
Implementing the LLVM part of the call to __builtin___clear_cache
which translates into an intrinsic @llvm.clear_cache and is lowered
by each target, either to a call to __clear_cache or nothing at all
incase the caches are unified.
Updating LangRef and adding some tests for the implemented architectures.
Other archs will have to implement the method in case this builtin
has to be compiled for it, since the default behaviour is to bail
unimplemented.
A Clang patch is required for the builtin to be lowered into the
llvm intrinsic. This will be done next.
llvm-svn: 204802
With VSX there is a real vector select instruction, and so we should use it.
Note that VSELECT will still scalarize for v2f64 because the corresponding
SetCC result type (v2i64) is not currently a legal type.
llvm-svn: 204801
These are aliases of t4-t7 and are provided for compatibility with both the
original ABI documentation (using t4-t7) and GNU As (using t0-t3)
llvm-svn: 204797
Summary: Added test cases for O32 and N32 on MIPS64.
Reviewers: matheusalmeida
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D3175
llvm-svn: 204796
This reveals a small mistake in mips-register-names.s ($sp is tested twice and
$s8 is not tested) which will be fixed in a follow-up commit.
llvm-svn: 204792
Hal Finkel