Constant fold int-to-long-double conversions;
use APFloat for int-to-float/double; use
round-to-nearest for these (implementation-defined,
seems to match gcc).

llvm-svn: 42484

Change APFloat::convertFromInteger to take the incoming
bit width instead of number of words allocated, which
makes it actually work for int->APF conversions.
Adjust callers. Add const to one of the

Change APFloat::convertFromInteger to take the incoming
bit width instead of number of words allocated, which
makes it actually work for int->APF conversions.
Adjust callers. Add const to one of the APInt constructors
to prevent surprising match when called with const
argument.

llvm-svn: 42210

show more ...

Implement x86 long double in jit (not really
complete, but common cases work)

llvm-svn: 42043

Next round of APFloat changes.
Use APFloat in UpgradeParser and AsmParser.
Change all references to ConstantFP to use the
APFloat interface rather than double. Remove
the ConstantFP double interface

Next round of APFloat changes.
Use APFloat in UpgradeParser and AsmParser.
Change all references to ConstantFP to use the
APFloat interface rather than double. Remove
the ConstantFP double interfaces.
Use APFloat functions for constant folding arithmetic
and comparisons.
(There are still way too many places APFloat is
just a wrapper around host float/double, but we're
getting there.)

llvm-svn: 41747

show more ...

Fix a comment typo noticed by Sandro Magi.

llvm-svn: 41018

Add comments to fallsthrough cases. Also, this fixes PR1492

llvm-svn: 37405

Check arguments & return types of main(). Abort in case of no match.

llvm-svn: 37404

Compute the correct word number.

llvm-svn: 37322

Unbreak C++ build.

llvm-svn: 35067

Fix all of last night's JIT failures in Prolangs-C++ by finishing the
implementation of getConstantValue().

llvm-svn: 34988

1. Make StoreValueToMemory a little more efficient by not requiring caller
to make a copy of the GenericValue.
2. Fix a copy & paste bug in StoreValueToMemory where 64-bit values were
truncated

1. Make StoreValueToMemory a little more efficient by not requiring caller
to make a copy of the GenericValue.
2. Fix a copy & paste bug in StoreValueToMemory where 64-bit values were
truncated to 32

llvm-svn: 34958

show more ...

Simplify things significantly because GenericValue now has a single integer
field, of type APInt, instead of multiple integer fields. Also, get rid of
the special endianness code in StoreValueToMemor

Simplify things significantly because GenericValue now has a single integer
field, of type APInt, instead of multiple integer fields. Also, get rid of
the special endianness code in StoreValueToMemory and LoadValueToMemory.
ExecutionEngine is always used to execute on the host platform so this is
now unnecessary.

llvm-svn: 34946

show more ...

Deal with error handling better.

llvm-svn: 34887

Avoid memory leakage by having caller construct the APInt for the
destination value of LoadValueFromMemory.

llvm-svn: 34883

Implement loading and storing of APInt values from memory.

llvm-svn: 34874

For PR1195:
Rename PackedType -> VectorType, ConstantPacked -> ConstantVector, and
PackedTyID -> VectorTyID. No functional changes.

llvm-svn: 34293

From Dan Gohman:

While preparing http://llvm.org/PR1198 I noticed several asserts
protecting unprepared code from i128 types that weren't actually failing
when they should because they were written

From Dan Gohman:

While preparing http://llvm.org/PR1198 I noticed several asserts
protecting unprepared code from i128 types that weren't actually failing
when they should because they were written as assert("foo") instead of
something like assert(0 && "foo"). This patch fixes all the cases that a
quick grep found.

llvm-svn: 34267

show more ...

eliminate use of TargetData::getIndexedOffset that takes a vector

llvm-svn: 34163

Privatize StructLayout::MemberOffsets, adding an accessor

llvm-svn: 34156

For PR411:
Adjust to changes in Module interface:
getMainFunction() -> getFunction("main")
getNamedFunction(X) -> getFunction(X)

llvm-svn: 33922

For PR1136: Rename GlobalVariable::isExternal as isDeclaration to avoid
confusion with external linkage types.

llvm-svn: 33663

For PR1043:
This is the final patch for this PR. It implements some minor cleanup
in the use of IntegerType, to wit:
1. Type::getIntegerTypeMask -> IntegerType::getBitMask
2. Type::Int*Ty changed to

For PR1043:
This is the final patch for this PR. It implements some minor cleanup
in the use of IntegerType, to wit:
1. Type::getIntegerTypeMask -> IntegerType::getBitMask
2. Type::Int*Ty changed to IntegerType* from Type*
3. ConstantInt::getType() returns IntegerType* now, not Type*

This also fixes PR1120.

Patch by Sheng Zhou.

llvm-svn: 33370

show more ...

Fix a regression in the last patch. When constructing a BitMask, be careful
not to overflow 64-bits and end up with a 0 mask. This caused i64 values to
always be stored as 0 with lots of consequentia

Fix a regression in the last patch. When constructing a BitMask, be careful
not to overflow 64-bits and end up with a 0 mask. This caused i64 values to
always be stored as 0 with lots of consequential damage to nightly test.

llvm-svn: 33335

show more ...

Make sure we truncate stored values to their bit width.

llvm-svn: 33317

For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.

This change doe

For PR1064:
Implement the arbitrary bit-width integer feature. The feature allows
integers of any bitwidth (up to 64) to be defined instead of just 1, 8,
16, 32, and 64 bit integers.

This change does several things:
1. Introduces a new Derived Type, IntegerType, to represent the number of
bits in an integer. The Type classes SubclassData field is used to
store the number of bits. This allows 2^23 bits in an integer type.
2. Removes the five integer Type::TypeID values for the 1, 8, 16, 32 and
64-bit integers. These are replaced with just IntegerType which is not
a primitive any more.
3. Adjust the rest of LLVM to account for this change.

Note that while this incremental change lays the foundation for arbitrary
bit-width integers, LLVM has not yet been converted to actually deal with
them in any significant way. Most optimization passes, for example, will
still only deal with the byte-width integer types. Future increments
will rectify this situation.

llvm-svn: 33113

show more ...