llvm-svn: 55615

I'll try to come up with a correct fix for the testcase sometime soon.

llvm-svn: 55614

llvm-svn: 55613

- warn about nonnull being applied to functions with no pointer arguments
- continue processing argument list in the attribute when we encounter a non-pointer parameter being marked as nonnull
- when no argument list is specified, only mark pointers as nonnull.  This fixes PR 2732 and radar 6188814.

llvm-svn: 55610

llvm-svn: 55609

The first can update the SDNode in an SDValue
while the second is called with SDNode* and
returns a possibly updated SDNode*.

This patch has no intended functional impact,
but helps eliminating ugly temporary SDValues.

llvm-svn: 55608

llvm-svn: 55607

(what matters is that it is added to the worklist),
it seems more logical to return it.

llvm-svn: 55606

llvm-svn: 55605

attributes on functions, based on the result of
alias analysis.  It's not hardwired to use
GlobalsModRef even though this is the only (AFAIK)
alias analysis that results in this pass actually
doing something.  Enable as follows:
  opt ... -globalsmodref-aa -markmodref ...
Advantages of this pass: (1) records the result
of globalsmodref in the bitcode, meaning it is
available for use by later passes (currently
the pass manager isn't smart enough to magically
make an advanced alias analysis available to all
later passes), which may expose more optimization
opportunities; (2) hopefully speeds up compilation
when code is optimized twice, for example when a
file is compiled to bitcode, then later LTO is done
on it: marking functions readonly/readnone when
producing the initial bitcode should speed up alias
analysis during LTO; (3) good for discovering that
globalsmodref doesn't work very well :)
Not currently turned on by default.

llvm-svn: 55604

llvm-svn: 55603

llvm-svn: 55601

llvm-svn: 55599

llvm-svn: 55598

llvm-svn: 55597

llvm-svn: 55596

llvm-svn: 55594

llvm-svn: 55593

llvm-svn: 55591

llvm-svn: 55590

"This minor patch adds markup of string literals with a red colour."

llvm-svn: 55589

llvm-svn: 55588

llvm-svn: 55583

instructions in CellSPU as "Expand" so that they won't be generated. I added a
"FIXME" so that this hack can be addressed and reverted once ISD::ROTR is
supported in the .td files.

llvm-svn: 55582

Dale, Could you please review this?

llvm-svn: 55581

llvm-svn: 55580

combiner can now generate ROTR if the backend says that it can handle it. Cell
SPU says this, but gets an error from code gen saying that it can't select
ROTR. I'm xfailing this test until this can be fixed.

llvm-svn: 55579

llvm-svn: 55578

llvm-svn: 55577

llvm-svn: 55576

   // fold (or (shl x, (*ext y)), (srl x, (*ext (sub 32, y)))) ->
   //   (rotl x, y)
   // fold (or (shl x, (*ext y)), (srl x, (*ext (sub 32, y)))) ->
   //   (rotr x, (sub 32, y))

Example: (x == 0xDEADBEEF and y == 4)

    (x << 4) | (x >> 28)
 => 0xEADBEEF0 | 0x0000000D
 => 0xEADBEEFD

    (rotl x, 4)
 => 0xEADBEEFD

    (rotr x, 28)
 => 0xEADBEEFD

- Fix comment and code for second version. It wasn't using the rot* propertly.

   // fold (or (shl x, (*ext (sub 32, y))), (srl x, (*ext r))) -> 
   //   (rotr x, y)
   // fold (or (shl x, (*ext (sub 32, y))), (srl x, (*ext r))) ->
   //   (rotl x, (sub 32, y))

    (x << 28) | (x >> 4)
 => 0xD0000000 | 0x0DEADBEE
 => 0xDDEADBEE

    (rotl x, 4)
 => 0xEADBEEFD

    (rotr x, 28)
 => (0xEADBEEFD)

llvm-svn: 55575

llvm-svn: 55574

Add CodeGenFunction::EmitMemSetToZero and make AggExprEmitter::EmitAggregateClear use it.

llvm-svn: 55573

llvm-svn: 55572

llvm-svn: 55571

Based on patch by Giorgos Korfiatis.

llvm-svn: 55570

access of methods.

llvm-svn: 55569

llvm-svn: 55568

llvm-svn: 55567

Breakage was exposed in the Ocaml bindings tests after Chris
uncommented an assertion in r55084.

llvm-svn: 55566