been using the default target data layout object to lower malloc instructions,
causing us to allocate more memory than we needed! This could improve the
performance of the CBE generated code substantially!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12088 91177308-0d34-0410-b5e6-96231b3b80d8
(16) into certain areas of the SPARC V9 back-end. I'm fairly sure the US IIIi's
dcache has 32-byte lines, so I'm not sure where the 16 came from. However, in
the interest of not breaking things any more than they already are, I'm going
to leave the constant alone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12043 91177308-0d34-0410-b5e6-96231b3b80d8
Functions with linkonce linkage are declared with weak linkage.
Global floating point constants used to represent unprintable values
(such as NaN and infinity) are declared static so that they don't interfere
with other CBE generated translation units.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11884 91177308-0d34-0410-b5e6-96231b3b80d8
longer was getting this #include, it always fell back on the less precise
floating point initializer values, causing some testsuite failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11803 91177308-0d34-0410-b5e6-96231b3b80d8
hacks can be banished. Also, this gives us the opportunity to emit special code
for the setjmp/longjmps which alows the elimination of one GCC warning for every
setjmp/longjmp site (which is often THOUSANDS in C++ programs). Yaay!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11484 91177308-0d34-0410-b5e6-96231b3b80d8
"expensive exceptions" controlled by an option. Also refactor and eliminate a bunch of cruft.
This is a temporary solution and causes millions of warnings to pour out of programs that use
exceptions, but it should fix the problem with sparc and the 'write' declaration (PR190).
Subsequent changes will make this stink much less
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11405 91177308-0d34-0410-b5e6-96231b3b80d8
the write() system call because it returns 64 bits on Solaris 64 bit,
and an implicit return value of int says it returns 32 bits.
Admittedly, this is a bit of a hack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10375 91177308-0d34-0410-b5e6-96231b3b80d8
storage duration that are local to the function containing the invocation of the
[...] setjmp macro that do not have volatile-qualified type and have been
changed between the setjmp invocation and longjmp call are indeterminate."
As such, we have to mark all variables in a function that uses 'invoke' as
volatile.
This fixes PR77
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10035 91177308-0d34-0410-b5e6-96231b3b80d8
* Print floating point values using C99 hexadecimal style FP if possible.
This increases the number of floating point constants that may be emitted
inline, and improves precision for global variable initializers which
can not be emitted in integer form.
This fixes the Olden/Power benchmark with the CBE!!!!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9052 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix isFPCSafeToPrint to find more constants safe to print, which it was
failing because ftostr was padding with leading space characters.
* Scan the entire module for global constants instead of each function at a
time. This has the advantage of allowing us to emit constants at global
scope instead of function scope. This speeds FP programs quite a bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9048 91177308-0d34-0410-b5e6-96231b3b80d8
