llvm-svn: 165639

llvm-svn: 165638

llvm-svn: 165636

...but do run them on user headers.

Previously, we were inconsistent here: non-path-sensitive checks on code
/bodies/ were only run in the main source file, but checks on
/declarations/ were run in /all/ headers. Neither of those is the
behavior we want.

Thanks to Sujit for pointing this out!

<rdar://problem/12454226>

llvm-svn: 165635

No functionality change.

llvm-svn: 165634

There are only two other instances of using `.. code::` instead of
`..  code-block::`.

llvm-svn: 165633

Hypothesis 1: use of `.. code::` directive instead of `.. code-block::`
is causing Sphinx to discard the block. On my machine, `.. code::`
renders fine. However, I don't think that `..  code::` is actually a
legit Sphinx directive. I believe that on my machine Sphinx is falling
back to just displaying it monospace with no syntax, whereas llvm.org's
Sphinx is just discarding it.

This is truly "remote debugging" since I can't reproduce this on my
machine. It would be helpful to be able to see the llvm.org Sphinx
build logs; if that's possible please let me know.

llvm-svn: 165632

- Due to the current matching vector elements constraints in
  ISD::FP_ROUND, rounding from v2f64 to v4f32 (after legalization from
  v2f32) is scalarized. Add a customized v2f32 widening to convert it
  into a target-specific X86ISD::VFPROUND to work around this
  constraints.

llvm-svn: 165631

Don't make regexp commands as regular commands - they are "short cuts" and users should be able to override them with "unalias" but you can't unalias normal commands. 

llvm-svn: 165630

Reading from a weak property, casting the result, and assigning to a
strong pointer should still be considered safe.

llvm-svn: 165629

Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl
(the latter by name) over to findPropertyDecl. This actually makes
-Wreceiver-is-weak a bit stronger than it was before.

llvm-svn: 165628

Old algorithm:
1. See if the name looks like a getter or setter.
2. Use the name to look up a property in the current ObjCContainer
   and all its protocols.
3. If the current container is an interface, also look in all categories
   and superclasses (and superclass categories, and so on).

New algorithm:
1. See if the method is marked as a property accessor. If so, look through
   all properties in the current container and find one that has a matching
   selector.
2. Find all overrides of the method using ObjCMethodDecl's
   getOverriddenMethods. This collects methods in superclasses and protocols
   (as well as superclass categories, which isn't really necessary), and
   checks if THEY are accessors. This part is not done recursively, since
   getOverriddenMethods is already recursive.

This lets us handle getters and setters that do not match the property
names.

llvm-svn: 165627

This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).

This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.

llvm-svn: 165626

- Due to the current matching vector elements constraints in ISD::FP_EXTEND,
  rounding from v2f32 to v2f64 is scalarized. Add a customized v2f32 widening
  to convert it into a target-specific X86ISD::VFPEXT to work around this
  constraints. This patch also reverts a previous attempt to fix this issue by
  recovering the scalarized ISD::FP_EXTEND pattern and thus significantly
  reduces the overhead of supporting non-power-2 vector FP extend.

llvm-svn: 165625

constructor with invalid code.

rdar://12240916

llvm-svn: 165623

llvm-svn: 165621

LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR=/path/to/llvm-srcroot/tools/clang/tools/extra, by default.

llvm-svn: 165620

FIXME: Would you like to run llvm/unittests w/o LLVM_BUILD_TESTS regardless of LLVM_BUILD_TOOLS?
llvm-svn: 165619

llvm-svn: 165618

SDNode for LDRB_POST_IMM is invalid: number of registers added to SDNode fewer
that described in .td.

7 ops is needed, but SDNode with only 6 is created.

In more details:
In ARMInstrInfo.td, in multiclass AI2_ldridx, in definition _POST_IMM, offset
operand is defined as am2offset_imm. am2offset_imm is complex parameter type,
and actually it consists from dummy register and imm itself. As I understood
trick with dummy reg was made for AsmParser. In ARMISelLowering.cpp, this dummy
register was not added to SDNode, and it cause crash in Peephole Optimizer pass.

The problem fixed by setting up additional dummy reg when emitting
LDRB_POST_IMM instruction.

llvm-svn: 165617

SchedulerDAGInstrs::buildSchedGraph ignores dependencies between FixedStack
objects and byval parameters. So loading byval parameters from stack may be
inserted *before* it will be stored, since these operations are treated as
independent.

Fix:
Currently ARMTargetLowering::LowerFormalArguments saves byval registers with
FixedStack MachinePointerInfo. To fix the problem we need to store byval
registers with MachinePointerInfo referenced to first the "byval" parameter.

Also commit adds two new fields to the InputArg structure: Function's argument
index and InputArg's part offset in bytes relative to the start position of
Function's argument. E.g.: If function's argument is 128 bit width and it was
splitted onto 32 bit regs, then we got 4 InputArg structs with same arg index,
but different offset values. 

llvm-svn: 165616

The issue arises when coercing to/from types of different sizes. We need
to be certain that the allocation on either end has sufficient room for
the coerced type. When it doesn't, we need to make room, copy across,
and then proceed. PR11905 handled the case of storing function arguments
back into allocas in the function prolog, this patch handles the case of
setting up the function arguments in a call expression.

This is actually significantly simpler than the fix for PR11905. It ends
up being a trivial change to create a temporary alloca when the source
is too small and memcpy across. This should preserve the compile-time
fast-isel benefits of doing gep+load sequences and avoiding FCAs.

Reviewed by Benjamin and Evgeniy (who fixed PR11905).

llvm-svn: 165615

llvm-svn: 165613

namespace. Use the attribute's enum value instead. No functionality change
intended.

llvm-svn: 165611

namespace. Use the attribute's enum value instead. No functionality change
intended.

llvm-svn: 165610

AAPCS ABI Section 7.1.4 [1] specifies that va_list
should be defined as struct __va_list { void *__ap;};
And in C++, it is defined in namespace std.

[1] http://infocenter.arm.com/help/topic
         /com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

Patch by Weiming Zhao.

llvm-svn: 165609

checkRegMaskInterference only initializes the bitmask on the first interference.

This fixes PR14027 and (re)fixes PR13945.

llvm-svn: 165608

enums. These are then created via the correct Attributes creation method.

llvm-svn: 165607

llvm-svn: 165606

llvm-svn: 165605

Consistently evaluate Aliases and Sequences recursively.

llvm-svn: 165604

Allows the new machine model to be used for NumMicroOps and OutputLatency.

Allows the HazardRecognizer to be disabled along with itineraries.

llvm-svn: 165603

llvm-svn: 165602

llvm-svn: 165601

llvm-svn: 165600

llvm-svn: 165599

llvm-svn: 165597

Have 'addFnAttr' take the attribute enum value. Then have it build the attribute object and add it appropriately. No functionality change.

llvm-svn: 165596

Have 'addFnAttr' take the attribute enum value. Then have it build the attribute object and add it appropriately. No functionality change.

llvm-svn: 165595

llvm-svn: 165594