to an object outside its lifetime does not have undefined behavior.

llvm-svn: 170387

Sadly, this costs us a perfectly good opportunity to use 'goto'.

llvm-svn: 170385

Most code is oblivious to bundles and uses the MBB::iterator which only
visits whole bundles. MBB::erase() operates on whole bundles at a time
as before.

MBB::remove() now refuses to remove bundled instructions. It is not safe
to remove all instructions in a bundle without deleting them since there
is no way of returning pointers to all the removed instructions.

MBB::remove_instr() and MBB::erase_instr() will now update bundle flags
correctly, lifting individual instructions out of bundles while leaving
the remaining bundle intact.

The MachineInstr convenience functions are updated so

  eraseFromParent() erases a whole bundle as before
  eraseFromBundle() erases a single instruction, leaving the rest of its bundle.
  removeFromParent() refuses to operate on bundled instructions, and
  removeFromBundle() lifts a single instruction out of its bundle.

These functions will no longer accidentally split or coalesce bundles -
bundle flags are updated to preserve the existing bundling, and explicit
bundleWith* / unbundleFrom* functions should be used to change the
instruction bundling.

This API update is still a work in progress. I am going to update APIs
first so they maintain bundle flags automatically when possible. Then
I'll add stricter verification of the bundle flags.

llvm-svn: 170384

It must be explicity set in MCPureStreamer because otherwise it will
inherit incorrectly from the parent.

llvm-svn: 170383

llvm-svn: 170381

llvm-svn: 170379

An extern declaration following a tentative definition should not itself be
considered a tentative definition.
Fixes pr14614.

llvm-svn: 170377

llvm-svn: 170376

llvm-svn: 170374

This also requires adding support to -cc1as for passing the detecting
PWD down through LLVM's debug info (which in turn required the LLVM
change in r170371).

The test case is weak (we only test the driver behavior) because there
is currently to infrastructure for running cc1as in the test suite. So
those four lines are untested (much like all other lines in that file),
but we have a test for the same pattern using llvm-mc in the LLVM
repository.

llvm-svn: 170373

Also, a few minor fixes:
- paragraph formatting
- capitalize "Python" where appropriate

llvm-svn: 170372

compilation directory.

This defaults to the current working directory, just as it always has,
but now an assembler can choose to override it with a custom directory.
I've taught llvm-mc about this option and added a test case.

llvm-svn: 170371

Send thread name using hex encoding.

llvm-svn: 170370

llvm-svn: 170369

llvm-svn: 170368

llvm-svn: 170367

Patch from Edwin Vane!

llvm-svn: 170366

No functionality change.

llvm-svn: 170365

llvm-svn: 170364

llvm-svn: 170363

llvm-svn: 170362

performance heuristic

After inlining a function with more than 13 basic blocks 32 times, we
are not going to inline it anymore. The idea is that inlining large
functions leads to drastic performance implications. Since the function
has already been inlined, we know that we've analyzed it in many
contexts. 

The following metrics are used:
 - Large function is a function with more than 13 basic blocks (we
should switch to another metric, like cyclomatic complexity)
 - We consider that we've inlined a function many times if it's been
inlined 32 times. This number is configurable with -analyzer-config
max-times-inline-large=xx

This heuristic addresses a performance regression introduced with
inlining on one benchmark. The analyzer on this benchmark became 60
times slower with inlining turned on. The heuristic allows us to analyze
it in 24% of the time. The performance improvements on the other
benchmarks I've tested with are much lower - under 10%, which is
expected.

llvm-svn: 170361

checks are in place.  Some minor cleanup as well.

llvm-svn: 170360

llvm-svn: 170355

llvm-svn: 170354

This was a silly oversight, we weren't pruning allocas which were used
by variable-length memory intrinsics from the set that could be widened
and promoted as integers. Fix that.

llvm-svn: 170353

This reverts commit r170344. Doesn't even compile.

llvm-svn: 170351

llvm-svn: 170350

llvm-svn: 170349

Patch by Chia-Hung Duan!

llvm-svn: 170348

llvm-svn: 170347

llvm-svn: 170346

llvm-svn: 170345

llvm-svn: 170344

They seem to work fine.

Patch by: Christian König

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <deathsimple@vodafone.de>
llvm-svn: 170343

Patch by: Christian König

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <deathsimple@vodafone.de>
llvm-svn: 170342

The Align parameter is a power of two, so 16 results in 64K
alignment. Additional to that even 16 byte alignment doesn't
make any sense, so just remove it.

Patch by: Christian König

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <deathsimple@vodafone.de>
llvm-svn: 170341

llvm-svn: 170339

This also cleans up a bit of the memcpy call rewriting by sinking some
irrelevant code further down and making the call-emitting code a bit
more concrete.

Previously, memcpy of a subvector would actually miscompile (!!!) the
copy into a single vector element copy. I have no idea how this ever
worked. =/ This is the memcpy half of PR14478 which we probably weren't
noticing previously because it didn't actually assert.

The rewrite relies on the newly refactored insert- and extractVector
functions to do the heavy lifting, and those are the same as used for
loads and stores which makes the test coverage a bit more meaningful
here.

llvm-svn: 170338

avoided.

This required a minor modification of the memoization as now the
"CurrentPenalty" depends on whether or not we break before the current
token. Therefore, the CurrentPenalty should not be memoized but added
after retrieving a value from memory. This should not affect the runtime
behavior.

llvm-svn: 170337