that we default to an ANY_EXTEND if no parameter attribute is set on the
result value of a function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32836 91177308-0d34-0410-b5e6-96231b3b80d8
- New target type "mingw" was introduced
- Same things for both mingw & cygwin are marked as "cygming" (as in
gcc)
- .lcomm is supported here, so allow LLVM to use it
- Correctly use underscored versions of setjmp & _longjmp for both mingw
& cygwin
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32833 91177308-0d34-0410-b5e6-96231b3b80d8
things: (1) preventing PR1071 and (2) working around missing parameter
attributes for bool type. (2) will be fixed shortly. When PR1071 is fixed,
this patch should be undone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32831 91177308-0d34-0410-b5e6-96231b3b80d8
1. Switch expression and cases are compared signed and are sign extended.
2. For function results needing extended, do SIGN_EXTEND if the SExtAttribute
is set and ZERO_EXTEND if the ZExtAttribute is set, otherwise just let
the Legalizer do ANY_EXTEND.
This fixes the recent regression in kimwitu++ and probably the llvm-gcc
bootstrap issue we had today.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32830 91177308-0d34-0410-b5e6-96231b3b80d8
result types. These tests are checking for sext behavior and it won't
happen unless requested with the parameter attribute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32828 91177308-0d34-0410-b5e6-96231b3b80d8
it used an undefined type name as a parameter argument. This bug in the
assembler has been fixed and it is now necessary to define the type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32826 91177308-0d34-0410-b5e6-96231b3b80d8
to MRegisterInfo. These allow the target to issue instructions to spill and
restore callee saved registers in case where individual stores / loads aren't
the correct / profitable choice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32820 91177308-0d34-0410-b5e6-96231b3b80d8
Tweak the RUN: lines of these tests to accommodate the renaming of
variables done by llvm-upgrade. The renaming occurs as a result of avoiding
name collisons for collapsed type planes. Conflicting names have a .u
(unsigned) or .s (signed) suffix added. This patch updates the grep
expression to accommodate the new names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32815 91177308-0d34-0410-b5e6-96231b3b80d8
Add a test case to ensure that llvm-upgrade retains correct semantics
for the previous definition of "cast to bool" which compared against null.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32812 91177308-0d34-0410-b5e6-96231b3b80d8
Revise the upgrade parser to keep track of types more faithfully and use
this information to resolve name conflicts resulting from collapsed type
planes. The type planes have collapsed because the integer types are now
signless so that uint and int became i32. Where two planes existed for uint
and int, only i32 exists. Any variable names depending on the type planes
to pmake the identifier unique would cause a conflict. This patch resolves
that conflict for many but not all cases.
Situations involving the integer types and pointers to them are handled
by this patch. However, there are corner cases that are not handled
well, such as:
%t1 = type { uint, int }
%t2 = type { int, uint }
void %myfunc(%t1* one, %t2* two) {
%var = load %t1* one
%var = load %t2* two
}
In the scenario above, %t1 and %t2 are really the same type: { i32, i32 }
Consequently attempting to name %var twice will yield a redefinition error
when assembled.
While this patch is sufficien to allow the llvm/test suite to pass, More
work needs to be to complete the handling of these corner cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32810 91177308-0d34-0410-b5e6-96231b3b80d8
The lookup of parameter attributes was offset by two because of the
additional operands in an invoke instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32801 91177308-0d34-0410-b5e6-96231b3b80d8
Update for signless integer types:
1. Replace [us]byte with i8
2. Replace [u]short with i16
3. Replace [u]int with i32
4. Replace [u]long with i64
5. Document the "define" keyword and use it in all examples.
6. Document parameter attributes and how they affect function types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32791 91177308-0d34-0410-b5e6-96231b3b80d8
Update the test suite to accommodate the change from signed integer types
to signless integer types. The changes were of only a few kinds:
1. Make sure llvm-upgrade is run on the source which does the bulk of the
changes automatically.
2. Change things like "grep 'int'" to "grep 'i32'"
3. In several tests bitcasting caused the same name to be reused in the
same type plane. These had to be manually fixed. The fix was (generally)
to leave the bitcast and provide the instruction with a new name. This
should not affect the semantics of the test. In a few cases, the
bitcasts were known to be superfluous and irrelevant to the test case
so they were removed.
4. One test case uses a bytecode file which needed to be updated to the
latest bytecode format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32789 91177308-0d34-0410-b5e6-96231b3b80d8
Three changes:
1. Convert signed integer types to signless versions.
2. Implement the @sext and @zext parameter attributes. Previously the
type of an function parameter was used to determine whether it should
be sign extended or zero extended before the call. This information is
now communicated via the function type's parameter attributes.
3. The interface to LowerCallTo had to be changed in order to accommodate
the parameter attribute information. Although it would have been
convenient to pass in the FunctionType itself, there isn't always one
present in the caller. Consequently, a signedness indication for the
result type and for each parameter was provided for in the interface
to this method. All implementations were changed to make the adjustment
necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32788 91177308-0d34-0410-b5e6-96231b3b80d8
