llvm-svn: 84894

llvm-svn: 84893

llvm-svn: 84892

llvm-svn: 84891

even when keys get RAUWed and deleted during its lifetime. By default the keys
act like WeakVHs, but users can pass a third template parameter to configure
how updates work and whether to do anything beyond updating the map on each
action.

It's also possible to automatically acquire a lock around ValueMap updates
triggered by RAUWs and deletes, to support the ExecutionEngine.

llvm-svn: 84890

llvm-svn: 84889

llvm-svn: 84888

llvm-svn: 84886

llvm-svn: 84885

llvm-svn: 84884

When replacing a template-id expression with a declaration reference expression after overloading completes, make sure to keep the qualifier. Still not ready with that test-case...

llvm-svn: 84880

llvm-svn: 84878

llvm-svn: 84873

Now with Clang-compatibility.

llvm-svn: 84872

  N::f<int>

keep track of the full nested-name-specifier. This is mainly QoI and
relatively hard to test; will try to come up with a printing-based
test once we also retain the explicit template arguments past overload
resolution.

llvm-svn: 84869

llvm-svn: 84868

simulating running on a different system.

llvm-svn: 84862

In the latest binutils the plugin-api.h needs this - without
it the LLVM gold plugin fails to compile.

llvm-svn: 84861

llvm-svn: 84860

before freeing them.

llvm-svn: 84859

of the struct (!) works correctly.

llvm-svn: 84853

llvm-svn: 84851

llvm-svn: 84849

When a template-id expression refers to a member function template, turn it into an (implicit) member access expression. Fixes PR5220

llvm-svn: 84848

Refactor our handling of implicit member reference expressions to get most of the logic out of BuildDeclarationNameExpr

llvm-svn: 84847

Move if-conversion before post-regalloc scheduling so the predicated instruction get scheduled properly.

llvm-svn: 84843

Load / store multiple was missing opportunites when the load / store bundles are at the end of the bb. Test case is already in, the bug is exposed by subsequent commit.

llvm-svn: 84842

 

llvm-svn: 84841

to libanalysis.  Instcombine shrinking... does this even 
make sense???

llvm-svn: 84840

Analysis/ConstantFolding.cpp.  This doesn't change the behavior of
instcombine but makes other clients of ConstantFoldInstruction
able to handle loads.  This was partially extracted from Eli's patch
in PR3152.

llvm-svn: 84836

This ensures that arrays of float3 are correctly padded.

llvm-svn: 84833

llvm-svn: 84832

llvm-svn: 84831

llvm-svn: 84830

llvm-svn: 84828

llvm-svn: 84827

llvm-svn: 84826

llvm-svn: 84825

llvm-svn: 84824

llvm-svn: 84823