Doesn't work, but needs to be enabled in order to get there.

llvm-svn: 281071

I ran into a situation where I wanted to print out the contents of
page 6 of a PDB as a binary blob, and there was no straightforward
way to do that.

In addition to adding that, this patch also adds the ability to dump
a stream by index as a binary blob, and it will stitch together all
the blocks and dump the whole thing as one seemingly contiguous
sequence of bytes.

llvm-svn: 281070

llvm-svn: 281069

There is a bug in CMakeLists which causes powerpc64le systems to be recognized as big-endian. This patch fixes the issue.

Differential Revision: https://reviews.llvm.org/D23626

llvm-svn: 281068

This simplifies a lot of code, and will actually be necessary for
an upcoming patch to serialize TPI record hash values.

The idea before was that visitors should be examining records, not
modifying them.  But this is no longer true with a visitor that
constructs a CVRecord from Yaml.  To handle this until now, we
were doing some fixups on CVRecord objects at a higher level, but
the code is really awkward, and it makes sense to just have the
visitor write the bytes into the CVRecord.  In doing so I uncovered
a few bugs related to `Data` and `RawData` and fixed those.

Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D24362

llvm-svn: 281067

llvm-svn: 281066

Implementation of missing OpenMP 4.0 API functions omp_get_default_device and omp_set_default_device.
Also, added support for the environment variable OMP_DEFAULT_DEVICE.

Differential Revision: https://reviews.llvm.org/D23587

llvm-svn: 281065

Reviewers: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D24400

llvm-svn: 281064

This writes the full sequence of type records described in
Yaml to the TPI stream of the PDB file.

Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D24316

llvm-svn: 281063

Treat filenames the same way in the text index as we do in the html
index. This is a follow-up to r281008 (an attempt to unbreak the
native_separators.c test on Windows).

Patch by Maggie Yi!

llvm-svn: 281062

llvm-svn: 281061

This can happen when the frontend knows the debug info will be emitted
somewhere else. Usually this happens for dynamic classes with out of
line constructors or key functions, but it can also happen when modules
are enabled.

llvm-svn: 281060

Fork off compatibility.ll for the 3.9 release. The *.bc file in this
commit was produced using a Release build of the release_39 branch.

llvm-svn: 281059

These tests are not working reliably.  I'm marking them
xfail until I resolve the issue.

Tracked by:
llvm.org/pr30299

llvm-svn: 281058

The logic for upgrading a class from a forward decl to a complete type
was not checking the debug info emission level before applying the
vtable optimization. This meant we ended up without debug info for a
class which was required to be complete. I noticed it because it
triggered an assertion during CodeView emission, but that's a separate
issue.

llvm-svn: 281057

Our limited debug info optimizations are breaking down at DLL
boundaries, so we're going to evaluate the size impact of these
settings, and possibly change the default.

Users should be able to override our settings, though.

llvm-svn: 281056

I was looking to fix a bug in getComplexity(), and these cases showed up as 
obvious failures. I'm not sure how to find these in general though.

llvm-svn: 281055

These were added in r281051, which, I am embarrassed to admit, has an
incomplete commit message that I forgot to update before pushing.  You
can ignore element (2) in that list.

llvm-svn: 281054

If a dynamic class contains a dllimport method, then assume the class
may not be constructed in this DLL, and therefore the vtable will live
in a different PDB.

This heuristic is still incomplete, and will miss things like abstract
base classes that are only constructed on one side of the DLL interface.
That said, this heuristic does detect some cases that are currently
problematic, and may be useful to other projects that don't use many
DLLs.

llvm-svn: 281053

This resolves "isl_space.c:1775: not a parameter space" errors I have seen
on two systems.

llvm-svn: 281052

1) On some platforms, sizeof(SDNodeBits) == 1, so we were only copying
one byte out of the bitfield when we wanted to copy two, and we were
leaving half of the return value of getRawSubclassData() undefined.

2) Something something bitfields, not sure exactly what the issue or fix
is, yet.  (TODO)

Summary:
Previously we were assuming that SDNodeBits covered all of SDNode's
anonymous subclass data bitfield union.  But that's not right; it might
have size 1, in which it clearly doesn't.

This patch adds a field that does cover the whole union and adds
static_asserts to ensure it stays correct.

Reviewers: ahatanak, chandlerc

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D24223

llvm-svn: 281051

Summary:
Prevously assembler parsed all literals as either 32-bit integers or 32-bit floating-point values. Because of this we couldn't support f64 literals.
E.g. in instruction "v_fract_f64 v[0:1], 0.5", literal 0.5 was encoded as 32-bit literal 0x3f000000, which is incorrect and will be interpreted as 3.0517578125E-5 instead of 0.5. Correct encoding is inline constant 240 (optimal) or 32-bit literal 0x3FE00000 at least.

With this change the way immediate literals are parsed is changed. All literals are always parsed as 64-bit values either integer or floating-point. Then we convert parsed literals to correct form based on information about type of operand parsed (was literal floating or binary) and type of expected instruction operands (is this f32/64 or b32/64 instruction).
Here are rules how we convert literals:
    - We parsed fp literal:
        - Instruction expects 64-bit operand:
            - If parsed literal is inlinable (e.g. v_fract_f64_e32 v[0:1], 0.5)
                - then we do nothing this literal
            - Else if literal is not-inlinable but instruction requires to inline it (e.g. this is e64 encoding, v_fract_f64_e64 v[0:1], 1.5)
                - report error
            - Else literal is not-inlinable but we can encode it as additional 32-bit literal constant
                - If instruction expect fp operand type (f64)
                    - Check if low 32 bits of literal are zeroes (e.g. v_fract_f64 v[0:1], 1.5)
                        - If so then do nothing
                    - Else (e.g. v_fract_f64 v[0:1], 3.1415)
                        - report warning that low 32 bits will be set to zeroes and precision will be lost
                        - set low 32 bits of literal to zeroes
                - Instruction expects integer operand type (e.g. s_mov_b64_e32 s[0:1], 1.5)
                    - report error as it is unclear how to encode this literal
        - Instruction expects 32-bit operand:
            - Convert parsed 64 bit fp literal to 32 bit fp. Allow lose of precision but not overflow or underflow
            - Is this literal inlinable and are we required to inline literal (e.g. v_trunc_f32_e64 v0, 0.5)
                - do nothing
                - Else report error
            - Do nothing. We can encode any other 32-bit fp literal (e.g. v_trunc_f32 v0, 10000000.0)
    - Parsed binary literal:
        - Is this literal inlinable (e.g. v_trunc_f32_e32 v0, 35)
            - do nothing
        - Else, are we required to inline this literal (e.g. v_trunc_f32_e64 v0, 35)
            - report error
        - Else, literal is not-inlinable and we are not required to inline it
            - Are high 32 bit of literal zeroes or same as sign bit (32 bit)
                - do nothing (e.g. v_trunc_f32 v0, 0xdeadbeef)
            - Else
                - report error (e.g. v_trunc_f32 v0, 0x123456789abcdef0)

For this change it is required that we know operand types of instruction (are they f32/64 or b32/64). I added several new register operands (they extend previous register operands) and set operand types to corresponding types:
'''
enum OperandType {
    OPERAND_REG_IMM32_INT,
    OPERAND_REG_IMM32_FP,
    OPERAND_REG_INLINE_C_INT,
    OPERAND_REG_INLINE_C_FP,
}
'''

This is not working yet:
    - Several tests are failing
    - Problems with predicate methods for inline immediates
    - LLVM generated assembler parts try to select e64 encoding before e32.
More changes are required for several AsmOperands.

Reviewers: vpykhtin, tstellarAMD

Subscribers: arsenm, kzhuravl, artem.tamazov

Differential Revision: https://reviews.llvm.org/D22922

llvm-svn: 281050

Fixed code that was not checked before on windows for me, because of testcases that are
disabled on that platform atm.

Inital commit message:
"[ELF] - Versionscript: do not treat non-wildcarded names as wildcards."
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:

GLIBCXX_3.4 {                                                                   
    extern "C++" {  
    "aaa*"
   }
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:

extern "C++" {                                                              
    "operator delete[](void*)";

Patch fixes the issue.

Differential revision: https://reviews.llvm.org/D24229

llvm-svn: 281049

[asan] Since r280945 fixed the OS X abort() problem, merge scariness_score_test.cc and make it a general test.

Summary: Merges back both scariness_score_test.cc files, since the Linux-specific version shouldn't be needed any more.

Reviewers: kcc, eugenis, vitalybuka

Subscribers: llvm-commits, kubabrecka

Differential Revision: https://reviews.llvm.org/D24347

llvm-svn: 281048

[Sparc][LEON] Removed the parts of the errata fixes implemented using inline assembly as this is not the desired behaviour for end-users. Small change to a unit test to implement this without requiring the inline assembly.

llvm-svn: 281047

Broken BB:
http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/27211

llvm-svn: 281046

Fixed code that was not checked by testcases that are disabled on windows.

Inital commit message:
"[ELF] - Versionscript: do not treat non-wildcarded names as wildcards."
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:

GLIBCXX_3.4 {                                                                   
    extern "C++" {  
    "aaa*"
   }
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:

extern "C++" {                                                              
    "operator delete[](void*)";

Patch fixes the issue.

Differential revision: https://reviews.llvm.org/D24229

llvm-svn: 281045

So model that directly in TTI::getIntImmCost().

llvm-svn: 281044

Tell TargetTransformInfo about this so ConstantHoisting is informed.

llvm-svn: 281043

Fixes issue with rL280927 identified by Mikael Holmén

llvm-svn: 281042

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/19703

llvm-svn: 281041

The CMPZ #0 disappears during peepholing, leaving just a tADDi3, tADDi8 or t2ADDri. This avoids having to materialize the expensive negative constant in Thumb-1, and allows a shrinking from a 32-bit CMN to a 16-bit ADDS in Thumb-2.

llvm-svn: 281040

This fixes the following compile time errors:

  error: unknown type name 'nullptr_t'; did you mean 'std::nullptr_t'

llvm-svn: 281039

Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:

GLIBCXX_3.4 {                                                                   
    extern "C++" {  
    "aaa*"
   }
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:

extern "C++" {                                                              
    "operator delete[](void*)";

Patch fixes the issue.

Differential revision: https://reviews.llvm.org/D24229

llvm-svn: 281038

These instructions were only necessary when type information was stored in the
MachineInstr (because only generic MachineInstrs possessed a type). Now that
it's in MachineRegisterInfo, COPY and PHI work fine.

llvm-svn: 281037

llvm-svn: 281036

We want each register to have a canonical type, which means the best place to
store this is in MachineRegisterInfo rather than on every MachineInstr that
happens to use or define that register.

Most changes following from this are pretty simple (you need an MRI anyway if
you're going to be doing any transformations, so just check the type there).
But legalization doesn't really want to check redundant operands (when, for
example, a G_ADD only ever has one type) so I've made use of MCInstrDesc's
operand type field to encode these constraints and limit legalization's work.

As an added bonus, more validation is possible, both in MachineVerifier and
MachineIRBuilder (coming soon).

llvm-svn: 281035

llvm-svn: 281034

This reverts commit r281022. Mips buildbot broke, due to unhandled register
class FCC.

llvm-svn: 281033

Subscribers: jaydeep, bhushan, slthakur, sdardis, lldb-commits
llvm-svn: 281032