component names such as "engine" do not expand to "jit" and hence to
the native target libraries for external users.

Thanks to arrowdodger for reporting and diagnosing the problem.

llvm-svn: 129444

related tweaks to ExprMapKeyType.

llvm-svn: 129443

llvm-svn: 129442

llvm-svn: 129441

llvm-svn: 129440

llvm-svn: 129439

From Vassil Vassilev: Give external source's last resort lookup a chance, even if an identifier could resolve to a builtin.

llvm-svn: 129438

llvm-svn: 129437

llvm-svn: 129436

llvm-svn: 129435

llvm-svn: 129434

llvm-svn: 129433

the max itself, so it is not easy to write a test case for this, but I added a
test case that would fail if the code in AsmPrinter were removed.

llvm-svn: 129432

evaluated and unevaluated contexts. Add some testing of sizeof and
typeid.

Both of the typeid tests added here were triggering warnings previously.
Now the one false positive is suppressed without suppressing the warning
on actually buggy code.

llvm-svn: 129431

llvm-svn: 129430

llvm-svn: 129429

alignment for its type, use the minimum of the specified alignment and the ABI
alignment. This fixes <rdar://problem/9275290>.

llvm-svn: 129428

take it!

I wasn't able to get __builtin_ia32_loaddqu to transform into an unaligned
load...I'll have to look into it further.

llvm-svn: 129427

llvm-svn: 129426

In Microsoft mode, within class scope, if a CXXScopeSpec's type is equal to the type of one of the base classes then downgrade the missing typename error to a warning. Up to now this is the only case I found where MSVC doesn't require "typename" at class scope. Really strange!
This fixes 1 error when parsing the MSVC 2008 header files.
Example:

template<class T> class A {
public:
  typedef int TYPE;
};
template<class T> class B : public A<T> {
public:
  A<T>::TYPE a; // no typename required because A<T> is a base class.
};

llvm-svn: 129425

llvm-svn: 129424

llvm-svn: 129423

Fix various minor bugs in the ARM instruction emulation code.

llvm-svn: 129422

Additional fixes:
Do something reasonable for subtargets with generic
itineraries by handle node latency the same as for an empty
itinerary. Now nodes default to unit latency unless an itinerary
explicitly specifies a zero cycle stage or it is a TokenFactor chain.

Original fixes:
UnitsSharePred was a source of randomness in the scheduler: node
priority depended on the queue data structure. I rewrote the recent
VRegCycle heuristics to completely replace the old heuristic without
any randomness. To make the ndoe latency adjustments work, I also
needed to do something a little more reasonable with TokenFactor. I
gave it zero latency to its consumers and always schedule it as low as
possible.

llvm-svn: 129421

llvm-svn: 129420

llvm-svn: 129419

llvm-svn: 129417

versions.

llvm-svn: 129416

    lldb_private::OptionGroup
    lldb_private::OptionGroupOptions

OptionGroup lets you define a class that encapsulates settings that you want
to reuse in multiple commands. It contains only the option definitions and the
ability to set the option values, but it doesn't directly interface with the
lldb_private::Options class that is the front end to all of the CommandObject
option parsing. For that the OptionGroupOptions class can be used. It aggregates
one or more OptionGroup objects and directs the option setting to the 
appropriate OptionGroup class. For an example of this, take a look at the 
CommandObjectFile and how it uses its "m_option_group" object shown below
to be able to set values in both the FileOptionGroup and PlatformOptionGroup
classes. The members used in CommandObjectFile are:

    OptionGroupOptions m_option_group;
    FileOptionGroup m_file_options;
    PlatformOptionGroup m_platform_options;

Then in the constructor for CommandObjectFile you can combine the option
settings. The code below shows a simplified version of the constructor:

CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) :
    CommandObject (...),
    m_option_group (interpreter),
    m_file_options (),
    m_platform_options(true)
{
    m_option_group.Append (&m_file_options);
    m_option_group.Append (&m_platform_options);
    m_option_group.Finalize();
}

We append the m_file_options and then the m_platform_options and then tell
the option group the finalize the results. This allows the m_option_group to
become the organizer of our prefs and after option parsing we end up with
valid preference settings in both the m_file_options and m_platform_options
objects. This also allows any other commands to use the FileOptionGroup and
PlatformOptionGroup classes to implement options for their commands.

Renamed:
    virtual void Options::ResetOptionValues();
to:
    virtual void Options::OptionParsingStarting();

And implemented a new callback named:

    virtual Error Options::OptionParsingFinished();
    
This allows Options subclasses to verify that the options all go together
after all of the options have been specified and gives the chance for the
command object to return an error. It also gives a chance to take all of the
option values and produce or initialize objects after all options have
completed parsing.

Modfied:

    virtual Error
    SetOptionValue (int option_idx, const char *option_arg) = 0;
    
to be:

    virtual Error
    SetOptionValue (uint32_t option_idx, const char *option_arg) = 0;

(option_idx is now unsigned).

llvm-svn: 129415

undergoes preprocessing.

llvm-svn: 129414

Implement the ones that were missing in the asm streamer.

llvm-svn: 129413

objective-c instead of crashing in IRgen.
// rdar://9154582.

llvm-svn: 129412

rdar://problem/9273947

llvm-svn: 129411

there is no reason to align them higher.
 - This roughly matches llvm-gcc's r126913.
 - It is an open question whether or not we should do this for cstring's in
   general (code size vs optimization potential), for now we just match llvm-gcc
   until someone wants to run some experiments.

llvm-svn: 129410

The ARMARM specifies these instructions as unpredictable when storing the
writeback register. This shouldn't affect code generation much since storing a
pointer to itself is quite rare.

llvm-svn: 129409

registers for fast allocation.

Fixes rdar://9207598

llvm-svn: 129408

llvm-svn: 129407

llvm-svn: 129406

llvm-svn: 129405

values are also transmitted through branches which cause side effects to
be skipped altogether.

llvm-svn: 129404