We are about to add enum attributes with AttrKind numbers >= 63. This means we cannot use AttrKind #63 to test for an invalid attribute number in the RAW format anymore. This patch changes the number of an invalid attribute to #255. There is no change to the character of the tests. Differential Revision: https://reviews.llvm.org/D64531 llvm-svn: 365722
Summary: This complements the earlier addition of IntrWriteMem and IntrWriteArgMem LLVM intrinsic properties, see D18291. Also start using the attribute for memset, memcpy, and memmove intrinsics, and remove their special-casing in BasicAliasAnalysis. Reviewers: reames, joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18714 llvm-svn: 274485
Summary: This patch introduces two new function attributes InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone. inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly Test cases have been updated. This revision uses this (https://github.com/llvm-mirror/llvm/commit/d001932f3a8aa1ebd1555162fdce365f011bc292) as reference. Reviewers: jmolloy, hfinkel Subscribers: reames, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15499 llvm-svn: 255778
This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other things to demote global variables to locals. llvm-svn: 252282
Since r199356, we've printed a warning when dropping debug info. r225562 started crashing on that, since it registered a diagnostic handler that only expected errors. This fixes the handler to expect other severities. As a side effect, it now prints "error: " at the start of error messages, similar to `llvm-as`. There was a testcase for r199356, but it only really checked the assembler. Move `test/Bitcode/drop-debug-info.ll` to `test/Assembler`, and introduce `test/Bitcode/drop-debug-info.3.5.ll` (and companion `.bc`) to test the bitcode reader. Note: tools/gold/gold-plugin.cpp has an equivalent bug, but I'm not sure what the best fix is there. I'll file a PR. llvm-svn: 230416
The bitcode reading interface used std::error_code to report an error to the callers and it is the callers job to print diagnostics. This is not ideal for error handling or diagnostic reporting: * For error handling, all that the callers care about is 3 possibilities: * It worked * The bitcode file is corrupted/invalid. * The file is not bitcode at all. * For diagnostic, it is user friendly to include far more information about the invalid case so the user can find out what is wrong with the bitcode file. This comes up, for example, when a developer introduces a bug while extending the format. The compromise we had was to have a lot of error codes. With this patch we use the DiagnosticHandler to communicate with the human and std::error_code to communicate with the caller. This allows us to have far fewer error codes and adds the infrastructure to print better diagnostics. This is so because the diagnostics are printed when he issue is found. The code that detected the problem in alive in the stack and can pass down as much context as needed. As an example the patch updates test/Bitcode/invalid.ll. Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the caller. A simple one like llvm-dis can just use fatal errors. The gold plugin needs a bit more complex treatment because of being passed non-bitcode files. An hypothetical interactive tool would make all bitcode errors non-fatal. llvm-svn: 225562
In order to create an ObjectFile implementation that uses bitcode files, we need to propagate the bitcode errors to the ObjectFile interface, so we need to convert it to use the same error handling as ObjectFile: error_code. llvm-svn: 193996
llvm-svn: 193738
llvm-svn: 193737