When forming the function type from a declarator, we look for an
overloadable attribute before issuing a diagnostic in C about a
function signature containing only .... When the attribute is present,
we allow such a declaration for compatibility with the overloading
rules in C++. However, we were not looking for the attribute in all of
the places it is legal to write it on a declarator and so we only
accepted the signature in some forms and incorrectly rejected the
signature in others.
We now check for the attribute preceding the declarator instead of only
being applied to the declarator directly.
Adapt the region builder signature to hand in the attributes of the created ops. The revision is a preparation step the support named ops that need access to the operation attributes during op creation.
Depends On D119692
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D119693
If the function types differ, the call arguments don't necessarily
correspon to the function arguments. It's likely not worthwhile to
handle this more precisely, but at least we shouldn't crash.
Group and reorder the classed defined by comprehension.py and add type annotations.
Depends On D119126
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D119692
Index attributes had no default value, which means the attribute values had to be set on the operation. This revision adds a default parameter to `IndexAttrDef`. After the change, every index attribute has to define a default value. For example, we may define the following strides attribute:
```
```
When using the operation the default stride is used if the strides attribute is not set. The mechanism is implemented using `DefaultValuedAttr`.
Additionally, the revision uses the naming index attribute instead of attribute more consistently, which is a preparation for follow up revisions that will introduce function attributes.
Depends On D119125
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D119126
We have to special-case 'u 8__uuidof [tz]' demangling for legacy
support. That handling is a little duplicative.
* It seems better to just push the single expected node.
* We can also use 'consumeIf' rather than open-coding the peeking and increment.
* We don't need the numLeft < 2 check, as if there are few than that
other paths will end up with detecting the error.
FWIW This simplifies a future change adding operator precedence.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119543
The output buffer growth algorithm had a few issues:
a) An off-by-one error in the initial size check, which uses
'>='. This error was safe, but could cause us to reallocate when there
was no need.
b) An inconsistency between the initial size check (>=) and the
post-doubling check (>). The latter was somewhat obscured by the
swapped operands.
c) There would be many reallocs with an initially-small buffer. Add a
little initialization hysteresis.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119177
This adds very basic combines for AVG nodes, mostly for constant folding
and handling degenerate (zero) cases. The code performs mostly the same
transforms as visitMULHS, adjusted for AVG nodes.
Constant folding extends to a higher bitwidth and drops the lowest bit.
For undef nodes, `avg undef, x` is transformed to x. There is also a
transform for `avgfloor x, 0` transforming to `shr x, 1`.
Differential Revision: https://reviews.llvm.org/D119559
When deciding where to split a block to insert stack guard checks, we should
move past any debug instructions we see that might (e.g.) be separating a tail
call from its frame wrangling.
This time, also don't run off the front of a basic block.
I've been using this triple in development for a while without issues,
it's passing check-llvm and check-clang.
(The above is the commit message, but the build is currently broken since
D114639, I intend to submit this once it's passing again and it's accepted in
review)
Differential Revision: https://reviews.llvm.org/D119331
Currently, code generation was creating weak symbols for derived type
descriptor global it could not find in the current compilation unit.
The rational is that:
- the derived type descriptors of external module derived types are
generated in the compilation unit that compiled the module so that
the type descriptor address is uniquely associated with the type.
- some types do not have derived type descriptors: the builtin derived
types used to create derived type descriptors. The runtime knows
about them and does not need them to accomplish the feat of
describing themselves. Hence, all unresolved derived type descriptors
in codegen cannot be assumed to be resolved at link time.
However, this caused immense debugging pain when, for some reasons, derived
type descriptor that should be generated were not. This caused random
runtime failures instead of a much cleaner link time failure.
Improve this situation by allowing codegen to detect the builtin derived
types that have no derived type descriptors and requiring the other
unresolved derived type descriptor to be resolved at link time.
Also make derived type descriptor constant data since this was a TODO
and makes the situation even cleaner. This requiring telling lowering
which compiler created symbols can be placed in read only memory. I
considered using PARAMETER, but I have mixed feeling using it since that
would cause the initializer expressions of derived type descriptor to
be invalid from a Fortran point of view since pointer targets cannot be
parameters. I do not want to start misusing Fortran attributes, even if
I think it is quite unlikely semantics would currently complain. I also
do not want to rely on the fact that all object symbols with the
CompilerCreated flags are currently constant data. This could easily
change in the future and cause runtime bugs if lowering rely on this
while the assumption is not loud and clear in semantics.
Instead, add a ReadOnly symbol flag to tell lowering that a compiler
generated symbol can be placed in read only memory.
Differential Revision: https://reviews.llvm.org/D119555
Make it clearer that this method is specifically for pointer
element types, and not other element types. This distinction will
be relevant in the future.
The somewhat unusual spelling is to make sure this does not show
up when grepping for getPointerElementType.
While this might be marginally more precise, we generally don't
bother with this in InstCombine, and let the IRBuilder assign the
debug location. I don't see why this one fold, out of the thousands
done in InstCombine, should be treated specially.
This pass doesn't have any limitations specific to FuncOp and it will be useful to be able to run it on other ops (e.g. gpu.func).
Differential Revision: https://reviews.llvm.org/D119662
The current FastISel code reuses the register for a bitcast that
doesn't change the IR type, but uses a reg-to-reg copy if it
changes the IR type without changing the MVT. However, we can
simply reuse the register in that case as well.
In particular, this avoids unnecessary reg-to-reg copies for pointer
bitcasts. This was found while inspecting O0 codegen differences
between typed and opaque pointers.
Differential Revision: https://reviews.llvm.org/D119432
This was deprecated before the LLVM 14 branch cut, remove the
method now.
As a temporary workaround, Type::getPointerElementType() can be
used instead.
See https://llvm.org/docs/OpaquePointers.html for information on
the opaque pointers migration.
At import of a member it may require that the record is already set to complete.
(For example 'computeDependence' at create of some Expr nodes.)
The record at this time may not be completely imported, the result of layout
calculations can be incorrect, but at least no crash occurs this way.
A good solution would be if fields of every encountered record are imported
before other members of all records. This is much more difficult to implement.
Differential Revision: https://reviews.llvm.org/D116155
Due to there are other required changes in
https://reviews.llvm.org/D118094, precommit these changes to ease
reviewing. Including:
- Remove *_thwart tests.
- Remove test for (x & y) + (~x & ~y)
- Fix incorrect uniitest committeed before
MSVC currently doesn't support 80 bits long double. But ICC does support
it on Windows. Besides, there're also some users asked for this feature.
We can find the discussions from stackoverflow, msdn etc.
Given Clang has already support `-mlong-double-80`, extending it to
support for Windows seems worthwhile.
Reviewed By: rnk, erichkeane
Differential Revision: https://reviews.llvm.org/D115441
ELF stubs generated from llvm-ifs lacks program headers, which prevents
llvm-ifs from parsing them properly as program headers are required by
llvm's own ELF libraries. This patch adds a few workaround bypass this
limitation.
Differential Revision: https://reviews.llvm.org/D116769
This patch adds DT_STRSZ into the dynamic section, which was absent
previously. This was a bug and caused failures in other tools.
Differential Revision: https://reviews.llvm.org/D117058
Previously D113336 makes RISCVTargetInfo::initFeatureMap return the results
processed by RISCVISAInfo, which only consists of ISA features and misses
non-ISA features like `relax` and `save-restore`.
This patch fixes the problem.
Reviewed By: junparser
Differential Revision: https://reviews.llvm.org/D119541
Third attempt to fix a bot failure from
634da7a1c6 on an Android bot:
https://lab.llvm.org/buildbot#builders/77/builds/14339
My last attempt used an approach from another test where chmod was not
working of using a bad character in the path name. But it looks like
this trick only works on Windows.
Instead, restore the original version of this test before my change at
634da7a1c6 and move the bad path test to
a new test file, marking it unsupported on Android.
The slab delta (used to link as if allocated at a specified address) should
remain constant.The update to the delta was accidentally introduced in
962a2479b5, but hasn't caused any failures as it only breaks in an obvious
way for multi-file exec uses (our regression tests are all -noexec, and tend to
be single-file).
No testcase here: this is an obscure utility for testing support, and an
uncommon use-case. If the slab allocator is ever moved into LLVM we could add
a unit test to catch this.
This enables fshl to be matched earlier on X86
%6 = lshr i32 %3, 1
%7 = select i1 %4, i32 -2147483648, i32 0
%8 = or i32 %6, %7
X86 uses i8 for shift amounts. SelectionDAGBuilder creates the
ISD::SRL with an i8 shift type. DAGCombiner turns the select into
an ISD::SHL. Prior to this patch it would use i32 for the shift
amount. fshl matching failed because the shift amounts have different
types. LegalizeDAG fixes the ISD::SHL shift amount to i8. This
allowed fshl matching to succeed.
With this patch, the ISD::SHL will be created with an i8 shift
amount. This allows the fshl to match immediately.
No test case beause we still end up with a fshl either way.
Nikita Popov