fir.class is treated similarly as fir.box - but it has one key
distinction which is that it doesn't hold an element type. Thus the
categorization logic was mishandling this case for this reason (and also
the fact that it assumed that a base object is always a fir.ref).
This PR improves this handling and adds appropriate test exercising both
a class and a class field to ensure categorization works.
Instead of looking up the narrower reduction type via getRecurrenceType
we can generate the needed extend directly at constructiond re-use the
truncated value from the loop.
PR: https://github.com/llvm/llvm-project/pull/141860
This PR ensures we correctly restore the cursor column after resizing
the statusline. To ensure we have space for the statusline, we have to
emit a newline to move up everything on screen. The newline causes the
cursor to move to the start of the next line, which needs to be undone.
Normally, we would use escape codes to save & restore the cursor
position, but that doesn't work here, as the cursor position may have
(purposely) changed. Instead, we move the cursor up one line using an
escape code, but we weren't restoring the column.
Interestingly, Editline was able to recover from this issue through the
LineInfo struct which contains the buffer and the cursor location, which
allows us to compute the column. This PR addresses the bug by having
Editline "refresh" the cursor position.
Fixes#134064
Remove Linker Optimization Hints (LOHs) from outlining candidates
instead of simply preventing outlining if LOH labels are found in the
candidate. This will improve the effectiveness of the machine outliner
when LOHs are enabled (which is the default).
In
https://discourse.llvm.org/t/loh-conflicting-with-machineoutliner/83279/1
it was observed that the machine outliner is much more effective when
LOHs are disabled. Rather than completely disabling LOH, this PR aims to
keep LOH in most places and removing them from outlined functions where
it could be illegal. Note that we are conservatively removing all LOHs
from outlined functions for simplicity, but I believe we could retain
LOHs that are in the intersection of all candidates.
It should be ok to remove these LOHs since these blocks are being
outlined anyway, which will harm performance much more than the gain
from keeping the LOHs.
This patch fixes:
llvm/lib/Analysis/IR2Vec.cpp:296:2: error: extra ';' outside of a
function is incompatible with C++98
[-Werror,-Wc++98-compat-extra-semi]
Changes to scale opcodes, types and args once in `IR2VecVocabAnalysis` so that we can avoid scaling each time while computing embeddings. This PR refactors the vocabulary to explicitly define 3 sections---Opcodes, Types, and Arguments---used for computing Embeddings.
(Tracking issue - #141817 ; partly fixes - #141832)
Relanding #143479 after fixes.
Removed `NumberOfFeatures` from the `FeatureIndex` enum as the number of features used depends on whether IR2Vec embeddings are used.
Fix `UnnamedAddrAttrName` being inserted twice into the `elidedAttrs`
list for the attribute dictionary printer in `GlobalOp` and `AliasOp`
print functions.
Parse friends into a new FriendInfo and serialize them in JSON. We keep track of the friend declaration's template and function information if applicable.
This change only matters when MLIR function inlining kicks in,
and I am still just experimenting with this.
The added LIT test shows the particular example where the current
TBAA assignment is incorrect:
```
subroutine bar(this)
...
end subroutine bar
function foo() result(res)
type(t) :: res
call bar(res)
end function foo
subroutine test(arg)
! %0 = fir.alloca !fir.type<_QMmTt{x:f32}> {bindc_name = ".result"}
type(t) :: var
var = foo()
! fir.save_result foo's result to %0 (temp-alloca)
! fir.declare %0 {uniq_name = ".tmp.func_result"}
! load from %0 -> store into var
arg = var%x
end subroutine test
```
One way for FIR inlining to handle `foo()` call is to substitute
all uses of the `res` alloca (inside `foo`) with uses of the temp-alloca
(inside `test`). This means that the temp-alloca is then used
by the code inside bar (e.g. to store something into it).
After the inlining, the innermost dominating fir.dummy_scope
for `fir.declare %0` is the one from `bar`. If we use this scope
for assigning TBAA to the load from temp-alloca, then it will be
in the same TBAA tree as the stores into `this` inside `bar`.
The load and the stores will have different sub-trees, because
`this` is a dummy argument, and temp-alloca is a local allocation.
So they will appear as non-conflicting while they are accessing
the same memory.
This change makes sure that all local allocations always
use the outermost scope.
Since std::move is nothing more than a cast, part of STL and not the
language itself, it's easy to provide a custom implementation if one
wishes not to include the entirety of <utility>.
Added flag (MoveFunction) provides a way to continue using this
essential check even with the custom implementation of moving.
---------
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
Context:
`vector.transfer_read` always requires a padding value. Most of its
builders take no `padding` value and assume the safe value of `0`.
However, this should be a conscious choice by the API user, as it makes
it easy to introduce bugs.
For example, I found several occasions while making this patch that the
padding value was not getting propagated (`vector.transfer_read` was
transformed into another `vector.transfer_read`). These bugs, were
always caused because of constructors that don't require specifying
padding.
Additionally, using `ub.poison` as a possible default value is better,
as it indicates the user "doesn't care" about the actual padding value,
forcing users to specify the actual padding semantics they want.
With that in mind, this patch changes the builders in
`vector.transfer_read` to always having a `std::optional<Value> padding`
argument. This argument is never optional, but for convenience users can
pass `std::nullopt`, padding the transfer read with `ub.poison`.
---------
Signed-off-by: Fabian Mora <fabian.mora-cordero@amd.com>
Since std::forward is nothing more than a cast, part of STL and not the
language itself, it's easy to provide a custom implementation if one
wishes not to include the entirety of <utility>.
Added flag (ForwardFunction) provides a way to continue using this
essential check even with the custom implementation of forwarding.
---------
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
The 'update' construct has 3 'var-list' clauses, device, self, and host.
Each has a pretty simple data-operand type syntax in the IR, so this
patch implements them as well. At least one of those is required to be
present on an 'update', so we cannot do any lowering without them.
Note that 'self' and 'host' are aliases.
In a case statement for Type::HLSLInlineSpirv, the first statment
returns, and the remaining statement are never executed. This removes
the dead code.
7d8e369443 (r2166484730)
Name resolution defers the analysis of all object pointer initializers
to the end of a specification part, including the default initializers
of derived type data pointer components. This deferment allows object
pointer initializers to contain forward references to objects whose
declarations appear later.
However, this deferment has the unfortunate effect of causing NULL
default initialization of such object pointer components when they do
not appear in structure constructors that are used as default
initializers, and their default initializers are required. So handle
object pointer default initializers of components as they appear, as
before.
Folding hands complex exponentiations with constant arguments off to the
native libm, and on a least on host, this can produce spurious warnings
about division by zero and invalid arguments. Handle the case of a zero
base specially to avoid that, and also emit better warnings for the
undefined 0.**0 and (0.,0.)**0 cases. And add a test for these warnings
and the existing related ones.
check-io.cpp was missing checks for the definability of logical-valued
specifiers in INQUIRE statements (e.g. EXIST=), and therefore also not
noting the definitions of those variables. This could lead to bogus
warnings about undefined function result variables, and also to missed
errors about immutable objects appearing in those specifiers.
Fixes https://github.com/llvm/llvm-project/issues/144453.
Adds a hint to the warning message to disable a warning and updates the
tests to expect this.
Also fixes a bug in the storage of canonical spelling of error flags so
that they are not used after free.
... due to their close relationship. MCSection's inline functions (e.g.
iterator) access MCFragment, and we want MCFragment's inline functions
to access MCSection similarly (#146307).
Pull Request: https://github.com/llvm/llvm-project/pull/146315
