A 'remark' is information that is not an error or a warning, but rather some
additional information provided to the user. In contrast to a 'note' a 'remark'
is an independent diagnostic, whereas a 'note' always depends on another
diagnostic.

A typical use case for remark nodes is information provided to the user, e.g.
information provided by the vectorizer about loops that have been vectorized.

llvm-svn: 202474

llvm-svn: 202473

A really simple patch marks the end of a lot of yak shaving :-)

llvm-svn: 202463

llvm-svn: 202460

Unfortunately, it is currently impossible to use a PatFrag as part of an output
pattern (the part of the pattern that has instructions in it) in TableGen.
Looking at the current implementation, this was clearly intended to work (there
is already code in place to expand patterns in the output DAG), but is
currently broken by the baked-in type-checking assumption and the order in which
the pattern fragments are processed (output pattern fragments need to be
processed after the instruction definitions are processed).

Fixing this is fairly simple, but requires some way of differentiating output
patterns from the existing input patterns. The simplest way to handle this
seems to be to create a subclass of PatFrag, and so that's what I've done here.

As a simple example, this allows us to write:

def crnot : OutPatFrag<(ops node:$in),
                       (CRNOR $in, $in)>;

def       : Pat<(not i1:$in),
                (crnot $in)>;

which captures the core use case: handling of repeated subexpressions inside
of complicated output patterns.

This will be used by an upcoming commit to the PowerPC backend.

llvm-svn: 202450

This is the data structure listed on Microsoft PE/COFF Spec Revision 8.3, p. 80.
The name of the struct is not mentioned in the Microsoft PE/COFF spec, so I made
it up.

llvm-svn: 202438

This is a temporary workaround for native arm linux builds:
PR18996: Changing regalloc order breaks "lencod" on native arm linux builds.

llvm-svn: 202433

llvm-svn: 202432

Some MC components like Target Streamers or Assembly Parsers
may need to access the relocation model in order to expand
some directives and/or assembly macros.

llvm-svn: 202418

We moved MCJIT to use native object formats a long time ago and R600
now uses ELF, so it was dead.

llvm-svn: 202408

Re-apply r200853, which should not crash after Clang plugins were converted to loadable modules in r201256.

llvm-svn: 202404

This reverts commit r202225, which may cause a performance regression.

llvm-svn: 202338

and update everything accordingly. This can be used to conditionalize
the amount of output in the backend based on the amount of debug
requested/metadata emission scheme by a front end (e.g. clang).

Paired with a commit to clang.

llvm-svn: 202332

llvm-svn: 202323

llvm-svn: 202321

llvm-svn: 202318

llvm-svn: 202316

llvm-svn: 202277

This fixes spurious warnings in llvm-link about the datalayout not matching.

Thanks to Zalman Stern for reporting the bug!

llvm-svn: 202276

We don't have any test with more than 6 address spaces, so a DenseMap is
probably not the correct answer.

An unsorted array would also be OK, but we have to sort it for printing anyway.

llvm-svn: 202275

llvm-svn: 202274

llvm-svn: 202264

The table argument is always 128-bit (and interpreted as <16 x i8>) so the
extra specifier for it is just clutter.

No user-visible behaviour change, so no tests.

llvm-svn: 202258

integers. Complements the interfaces it is wrapping.

llvm-svn: 202251

llvm-svn: 202225

Delete two declared overloads of CallInst::CallInst that are never defined or used. No functionality change.

llvm-svn: 202218

llvm-svn: 202213

This will be used for testcases in CFE.

llvm-svn: 202207

Prevent a crash in the SmallDenseMap copy constructor whenever the other
map is not in small mode.

<rdar://problem/14292693>

llvm-svn: 202206

Eventually DataLayoutPass should go away, but for now that is the only easy
way to get a DataLayout in some APIs. This patch only changes the ones that
have easy access to a Module.

One interesting issue with sometimes using DataLayoutPass and sometimes
fetching it from the Module is that we have to make sure they are equivalent.
We can get most of the way there by always constructing the pass with a Module.
In fact, the pass could be changed to point to an external DataLayout instead
of owning one to make this stricter.

Unfortunately, the C api passes a DataLayout, so it has to be up to the caller
to make sure the pass and the module are in sync.

llvm-svn: 202204

No tool does this currently, but as everything else in a module we should be
able to change its DataLayout.

Most of the fix is in DataLayout to make sure it can be reset properly.

The test uses Module::setDataLayout since the fact that we mutate a DataLayout
is an implementation detail. The module could hold a OwningPtr<DataLayout> and
the DataLayout itself could be immutable.

Thanks to Philip Reames for pushing me in the right direction.

llvm-svn: 202198

Now that DataLayout is not a pass, store one in Module.

Since the C API expects to be able to get a char* to the datalayout description,
we have to keep a std::string somewhere. This patch keeps it in Module and also
uses it to represent modules without a DataLayout.

Once DataLayout is mandatory, we should probably move the string to DataLayout
itself since it won't be necessary anymore to represent the special case of a
module without a DataLayout.

llvm-svn: 202190

Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.

Paired commit with CFE r202185.

rdar://problem/13690847

This re-applies r202184 + a bugfix in DwarfDebug's argument handling.

llvm-svn: 202188

This reverts commit r202184 because of buildbot breakage.

llvm-svn: 202187

Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.

Paired commit with CFE.

rdar://problem/13690847

llvm-svn: 202184

llvm-svn: 202172

llvm-svn: 202171

Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM
don't don't handle passes to also use DataLayout.

llvm-svn: 202168

These complement many of the existing accessors and make it
significantly easier to write code which needs to poke at the underlying
Use without hard coding the operand number at which it resides for
a particular instruction. No functionality changed of course.

llvm-svn: 202102

llvm-svn: 202091