Commit Graph

168125 Commits

Author SHA1 Message Date
NAKAMURA Takumi 55a02eaa82 [CMake] Apply DEPENDS intrinsics_gen in clangCodeGen.
llvm-svn: 202237
2014-02-26 06:33:27 +00:00
NAKAMURA Takumi 9f4ee24ac6 lldReaderWriter: move LLVM_LINK_COMPONENTS. It seems Subdirectories don't depend on LLVMObject.
Please give LLVMObject explicitly in each subdirectory if any of subdirectories required it.

llvm-svn: 202236
2014-02-26 06:28:09 +00:00
NAKAMURA Takumi 23850261c6 [CMake] Declare cmake_minimum_required() unconditionally.
llvm-svn: 202235
2014-02-26 06:27:59 +00:00
Craig Topper c30b81ea06 [x86] Remove some unused instruction format classes.
llvm-svn: 202234
2014-02-26 06:06:38 +00:00
Craig Topper e413b628f8 [x86] Simplify disassembler code slightly.
llvm-svn: 202233
2014-02-26 06:01:21 +00:00
Chandler Carruth 181ed05b6a [SROA] The original refactoring inspired by the addrspace patch in
D1764, which in turn set off the other refactorings to make
'getSliceAlign()' a sensible thing.

There are two possible inputs to the required alignment of a memory
transfer intrinsic: the alignment constraints of the source and the
destination. If we are *only* introducing a (potentially new) offset
onto one side of the transfer, we don't need to consider the alignment
constraints of the other side. Use this to simplify the logic feeding
into alignment computation for unsplit transfers.

Also, hoist the clamp of the magical zero alignment for these intrinsics
to the more customary one alignment early. This lets several other
conditions melt away.

No functionality changed. There is a further improvement this exposes
which *will* change functionality, but that's arriving in a separate
patch.

llvm-svn: 202232
2014-02-26 05:33:36 +00:00
Chandler Carruth 47954c80ed [SROA] Yet another slight refactoring that simplifies an API in the
rewriting logic: don't pass custom offsets for the adjusted pointer to
the new alloca.

We always passed NewBeginOffset here. Sometimes we spelled it
BeginOffset, but only when they were in fact equal. Whats worse, the API
is set up so that you can't reasonably call it with anything else -- it
assumes that you're passing it an offset relative to the *original*
alloca that happens to fall within the new one. That's the whole point
of NewBeginOffset, it's the clamped beginning offset.

No functionality changed.

llvm-svn: 202231
2014-02-26 05:12:43 +00:00
Chandler Carruth 2659e503c3 [SROA] Simplify the computing of alignment: we only ever need the
alignment of the slice being rewritten, not any arbitrary offset.

Every caller is really just trying to compute the alignment for the
whole slice, never for some arbitrary alignment. They are also just
passing a type when they have one to see if we can skip an explicit
alignment in the IR by using the type's alignment. This makes for a much
simpler interface.

Another refactoring inspired by the addrspace patch for SROA, although
only loosely related.

llvm-svn: 202230
2014-02-26 05:02:19 +00:00
Chandler Carruth 735d5bee48 [SROA] Use NewOffsetBegin in the unsplit case for memset merely for
consistency with memcpy rewriting, and fix a latent bug in the alignment
management for memset.

The alignment issue is that getAdjustedAllocaPtr is computing the
*relative* offset into the new alloca, but the alignment isn't being set
to the relative offset, it was using the the absolute offset which is
into the old alloca.

I don't think its possible to write a test case that actually reaches
this code where the resulting alignment would be observably different,
but the intent was clearly to use the relative offset within the new
alloca.

llvm-svn: 202229
2014-02-26 04:45:24 +00:00
Chandler Carruth ea27cf08d8 [SROA] Use the members for New{Begin,End}Offset in the rewrite helpers
rather than passing them as arguments.

While I generally prefer actual arguments, in this case the readability
loss is substantial. By using members we avoid repeatedly calculating
the offsets, and once we're using members it is useful to ensure that
those names *always* refer to the original-alloca-relative new offset
for a rewritten slice.

No functionality changed. Follow-up refactoring, all toward getting the
address space patch merged.

llvm-svn: 202228
2014-02-26 04:25:04 +00:00
Chandler Carruth c46b6eb302 [SROA] Compute the New{Begin,End}Offset values once for each alloca
slice being rewritten.

We had the same code scattered across most of the visits. Instead,
compute the new offsets and the slice size once when we start to visit
a particular slice, and use the member variables from then on. This
reduces quite a bit of code duplication.

No functionality changed. Refactoring inspired to make it easier to
apply the address space patch to SROA.

llvm-svn: 202227
2014-02-26 04:20:00 +00:00
NAKAMURA Takumi 6a14c21dbf clang/test/CodeGenCXX/debug-info-varargs.cpp: Appease msvc with %itanium_abi_triple.
llvm-svn: 202226
2014-02-26 03:30:03 +00:00
Ben Langmuir 6a2a14da81 Use StringRef in raw_fd_ostream constructor
llvm-svn: 202225
2014-02-26 03:21:00 +00:00
Chandler Carruth 6aedc106ba [SROA] Fix PR18615 with some long overdue simplifications to the bounds
checking in SROA.

The primary change is to just rely on uge for checking that the offset
is within the allocation size. This removes the explicit checks against
isNegative which were terribly error prone (including the reversed logic
that led to PR18615) and prevented us from supporting stack allocations
larger than half the address space.... Ok, so maybe the latter isn't
*common* but it's a silly restriction to have.

Also, we used to try to support a PHI node which loaded from before the
start of the allocation if any of the loaded bytes were within the
allocation. This doesn't make any sense, we have never really supported
loading or storing *before* the allocation starts. The simplified logic
just doesn't care.

We continue to allow loading past the end of the allocation in part to
support cases where there is a PHI and some loads are larger than others
and the larger ones reach past the end of the allocation. We could solve
this a different and more conservative way, but I'm still somewhat
paranoid about this.

llvm-svn: 202224
2014-02-26 03:14:14 +00:00
Richard Trieu a170f08109 Remove 'tctx->name' from a logical statement since it is a pointer and always
is converted to a true value.  Detected by Clang's improved -Wbool-conversion

llvm-svn: 202223
2014-02-26 03:12:51 +00:00
Nick Lewycky ea08c7090b Remove spurious emacs major mode marker, these should only go on .h files.
llvm-svn: 202222
2014-02-26 03:10:45 +00:00
Eric Christopher f9761a294a 80-col.
llvm-svn: 202221
2014-02-26 02:53:18 +00:00
Eric Christopher 73ffdb8b3c Formatting fixups.
llvm-svn: 202220
2014-02-26 02:50:56 +00:00
Eric Christopher 0a1301fe25 80-col and bad line ending fixups.
llvm-svn: 202219
2014-02-26 02:49:36 +00:00
Nick Lewycky d883a1c148 Delete two declared overloads of CallInst::CallInst that are never defined or used. No functionality change.
llvm-svn: 202218
2014-02-26 02:39:43 +00:00
Rui Ueyama aaf2816d59 [PECOFF] Add a utility function to add DIR32 relocation.
llvm-svn: 202217
2014-02-26 02:38:40 +00:00
Richard Trieu 3bb8b56a5d PR16074, implement warnings to catch pointer to boolean true and pointer to
null comparison when the pointer is known to be non-null.

This catches the array to pointer decay, function to pointer decay and
address of variables.  This does not catch address of function since this
has been previously used to silence a warning.

Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.

void foo() {
  int arr[5];
  int x;
  // warn on these conditionals
  if (foo);
  if (arr);
  if (&x);
  if (foo == null);
  if (arr == null);
  if (&x == null);

  if (&foo);  // no warning
}

llvm-svn: 202216
2014-02-26 02:36:06 +00:00
Rui Ueyama f9be75f538 [PECOFF] Fix DLLCharacteristics field.
IMAGE_DLL_CHARACTERISTICS_NO_SEH flag should be set only when SEH is disabled.

llvm-svn: 202215
2014-02-26 02:31:53 +00:00
Marshall Clow 16da324051 Implement LWG issue 2306: match_results::reference should be value_type&, not const value_type&. This is a general move by the LWG to have the reference type of read-only containers be a non-const reference; however, there are no methods that return a non-const reference to a match_result entry, so there's no worries about getting a non-const reference to a constant object.
llvm-svn: 202214
2014-02-26 01:56:31 +00:00
Paul Robinson 0c12b1d23c Constify the Optnone checks in IR passes.
llvm-svn: 202213
2014-02-26 01:23:26 +00:00
Jordan Rose e359d0168f [analyzer] NonNullParamChecker: don't freak out about nested transparent_unions.
For now, just ignore them. Later, we could try looking through LazyCompoundVals,
but we at least shouldn't crash.

<rdar://problem/16153464>

llvm-svn: 202212
2014-02-26 01:20:19 +00:00
Richard Trieu 7eb0b2c181 Add -Wabsolute-value, warnings about absolute value functions.
The warnings fall into three groups.
1) Using an absolute value function of the wrong type, for instance, using the
int absolute value function when the argument is a floating point type.
2) Using the improper sized absolute value function, for instance, using abs
when the argument is a long long.  llabs should be used instead.

From these two cases, an implicit conversion will occur which may cause
unexpected behavior.  Where possible, suggest the proper absolute value
function to use, and which header to include if the function is not available.

3) Taking the absolute value of an unsigned value.  In addition to this warning,
suggest to remove the function call.  This usually indicates a logic error
since the programmer assumed negative values would have been possible.

llvm-svn: 202211
2014-02-26 01:17:28 +00:00
Rui Ueyama 5500b07c78 Simplify base64 routine a bit.
llvm-svn: 202210
2014-02-25 23:49:11 +00:00
Mark Seaborn 202169afa1 Exception handling docs: Describe landingpad clauses' meanings in more detail
The original text is very terse, so I've expanded on it.

Specifically, in the original text:

 * "The selector value is a positive number if the exception matched a
   type info" -- It wasn't clear that this meant "if the exception
   matched a 'catch' clause".

 * "If nothing is matched, the behavior of the program is
   `undefined`_."  -- It's actually implementation-defined in C++
   rather than undefined, as the new text explains.

llvm-svn: 202209
2014-02-25 23:48:59 +00:00
Adrian Prantl 800faef380 Address review comments for r202185, no functionality changes.
llvm-svn: 202208
2014-02-25 23:42:18 +00:00
Adrian Prantl b363c30b5d Add DIUnspecifiedParameter, so we can pretty-print it.
This will be used for testcases in CFE.

llvm-svn: 202207
2014-02-25 23:42:11 +00:00
Duncan P. N. Exon Smith 0d64f8b0ca fix crash in SmallDenseMap copy constructor
Prevent a crash in the SmallDenseMap copy constructor whenever the other
map is not in small mode.

<rdar://problem/14292693>

llvm-svn: 202206
2014-02-25 23:35:13 +00:00
Enrico Granata c6f0a6ac27 <rdar://problem/15593026>
Fix the algorithm used to detect a loop in a std::list

llvm-svn: 202205
2014-02-25 23:34:40 +00:00
Rafael Espindola 339430f993 Use DataLayout from the module when easily available.
Eventually DataLayoutPass should go away, but for now that is the only easy
way to get a DataLayout in some APIs. This patch only changes the ones that
have easy access to a Module.

One interesting issue with sometimes using DataLayoutPass and sometimes
fetching it from the Module is that we have to make sure they are equivalent.
We can get most of the way there by always constructing the pass with a Module.
In fact, the pass could be changed to point to an external DataLayout instead
of owning one to make this stricter.

Unfortunately, the C api passes a DataLayout, so it has to be up to the caller
to make sure the pass and the module are in sync.

llvm-svn: 202204
2014-02-25 23:25:17 +00:00
Marshall Clow 11918cff19 Mark LWG issue 2299 as complete. No code changes; libc++ already implements this.
llvm-svn: 202203
2014-02-25 23:11:19 +00:00
Adrian Prantl 6aa7616355 Attempt to unbreak an MSVC buildbot by switching to %llc_dwarf.
llvm-svn: 202202
2014-02-25 23:03:00 +00:00
David Blaikie 20474106a1 DwarfDebug: Avoid emitting an empty debug_aranges section when aranges are disabled
llvm-svn: 202201
2014-02-25 22:46:44 +00:00
Ted Kremenek c1b2875e69 Hoist culling of -Wunreachable-code from headers before we even run the analysis.
llvm-svn: 202200
2014-02-25 22:35:37 +00:00
Adrian Prantl 69140d2c0f Address review comments for r202188.
This is refactoring / simplifying code, updating comments and enabling the
testcase on non-x86 platforms.

No functionality change.

llvm-svn: 202199
2014-02-25 22:27:14 +00:00
Rafael Espindola 248ac13975 Fix resetting the DataLayout in a Module.
No tool does this currently, but as everything else in a module we should be
able to change its DataLayout.

Most of the fix is in DataLayout to make sure it can be reset properly.

The test uses Module::setDataLayout since the fact that we mutate a DataLayout
is an implementation detail. The module could hold a OwningPtr<DataLayout> and
the DataLayout itself could be immutable.

Thanks to Philip Reames for pushing me in the right direction.

llvm-svn: 202198
2014-02-25 22:23:04 +00:00
Alp Toker afc9eb33fd Restore string match behavior following changes in r202018
llvm-svn: 202197
2014-02-25 22:04:37 +00:00
Chandler Carruth 7b8e112407 [reassociate] Switch two std::sort calls into std::stable_sort calls as
their inputs come from std::stable_sort and they are not total orders.

I'm not a huge fan of this, but the really bad std::stable_sort is right
at the beginning of Reassociate. After we commit to stable-sort based
consistent respect of source order, the downstream sorts shouldn't undo
that unless they have a total order or they are used in an
order-insensitive way. Neither appears to be true for these cases.
I don't have particularly good test cases, but this jumped out by
inspection when looking for output instability in this pass due to
changes in the ordering of std::sort.

llvm-svn: 202196
2014-02-25 21:54:50 +00:00
Tom Stellard fd0d86c322 R600: Don't unconditionally unroll loops with private memory accesses
This causes the size of the scrypt kernel to explode and eats all the
memory on some systems.

llvm-svn: 202195
2014-02-25 21:36:21 +00:00
Tom Stellard 1f15bff0df R600/SI: Custom select 64-bit ADD
llvm-svn: 202194
2014-02-25 21:36:18 +00:00
Chandler Carruth 3b79b2ab4e [SROA] Add an off-by-default *strict* inbounds check to SROA. I had SROA
implemented this way a long time ago and due to the overwhelming bugs
that surfaced, moved to a much more relaxed variant. Richard Smith would
like to understand the magnitude of this problem and it seems fairly
harmless to keep some flag-controlled logic to get the extremely strict
behavior here. I'll remove it if it doesn't prove useful.

llvm-svn: 202193
2014-02-25 21:24:45 +00:00
Hal Finkel 22304046c7 Account for 128-bit integer operations in PPCCTRLoops
We need to abort the formation of counter-register-based loops where there are
128-bit integer operations that might become function calls.

llvm-svn: 202192
2014-02-25 20:51:50 +00:00
Rafael Espindola 449d3b7493 Don't try to set a dummy DataLayout. It is parsed now.
llvm-svn: 202191
2014-02-25 20:41:28 +00:00
Rafael Espindola f863ee2949 Store a DataLayout in Module.
Now that DataLayout is not a pass, store one in Module.

Since the C API expects to be able to get a char* to the datalayout description,
we have to keep a std::string somewhere. This patch keeps it in Module and also
uses it to represent modules without a DataLayout.

Once DataLayout is mandatory, we should probably move the string to DataLayout
itself since it won't be necessary anymore to represent the special case of a
module without a DataLayout.

llvm-svn: 202190
2014-02-25 20:01:08 +00:00
Jim Ingham 5689a217e3 Switch debugserver to detach on error by default, and change the flag to kill-on-error.
Also fix the bug where lldb prints: "Got a connection and launched debugserver" rather
than the name of the process it actually launched.

llvm-svn: 202189
2014-02-25 19:57:47 +00:00
Adrian Prantl 3f49c890bf Debug info: Support variadic functions.
Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.

Paired commit with CFE r202185.

rdar://problem/13690847

This re-applies r202184 + a bugfix in DwarfDebug's argument handling.

llvm-svn: 202188
2014-02-25 19:57:42 +00:00