Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AutoBump] Merge with be6aed90 (Sep 26) (1) #437

Merged
merged 14 commits into from
Jan 10, 2025

Conversation

mgehre-amd
Copy link
Collaborator

No description provided.

perry-ca and others added 14 commits September 26, 2024 14:11
Several lit tests look for messages with text generated from strerror()
such as "no such file or directory". The value can change slightly from
system to system. Use the llvm-lit macro `%errc_<ERRCODE>` instead.

This was really noticable on z/OS because the generated text includes an
error code as well as the text.
Unify logic for mayWriteToMemory and mayHaveSideEffects for
VPInstruction, with the later relying on the former. Also extend to
handle binary operators.

Split off from llvm#106441
The register encoding used by NVPTX and cuda-gdb basically use strings
encoded as numbers. They are always within 64-bits, but typically
outside of 32-bits, since they often need at least 5 characters.

This patch changes the signature of `MCRegisterInfo::getDwarfRegNum` and
some related data structures to use 64-bit numbers to accommodate
encodings like this.

Additionally, `MCRegisterInfo::getDwarfRegNum` is marked as virtual, so
that targets with peculiar dwarf register mapping schemes (such as
NVPTX) can override its behavior.

I originally tried to do a broader switch to 64-bit types for registers,
but it caused many problems. There are various places in code generation
where registers are not just treated as 32-bit numbers, but also treat
certain bit offsets as flags. So I limited the change as much as
possible to just the output of `getDwarfRegNum`. Keeping the types used
by `DwarfLLVMRegPair` as unsigned preserves the current behaviors. The
only way to give a 64-bit output from `getDwarfRegNum` that actually
needs more than 32-bits is to override `getDwarfRegNum` and provide an
implementation that sidesteps the use of the `DwarfLLVMRegPair` maps
defined in tablegen files.

First layer of stack supporting:
llvm#109495
This patch adds support for encoding PTX registers for DWARF, using the
encoding supported by nvcc and cuda-gcc.

There are some other features still needed for proper register debugging
that this patch does not address, such as DW_AT_address_class.

This PR is stacked on: llvm#109494
Summary:
We define this on AMDGCN but not NVPTX, which leads to some failures
dependong on the target.
Add support for -fdiagnostics-color and -fdiagnostics-color=. Add
documentation for -fdiagnostics-color= which should also be visible in
clang.

Partially addresses requests in llvm#89888
…09973)

Fold dim ops of iter_args to dim ops of their respective init args.
E.g.:

```
 %0 = ... : tensor<?x?xf32>
 scf.forall ... shared_outs(%arg0 = %0) -> (tensor<?x?xf32>) {
   %1 = tensor.dim %arg0, %c0 : tensor<?x?xf32>
   ...
 }
```
 is folded to:

```

 %0 = ... : tensor<?x?xf32>
 scf.forall ... shared_outs(%arg0 = %0) -> (tensor<?x?xf32>) {
   %1 = tensor.dim %0, %c0 : tensor<?x?xf32>
   ...
 }
```
This patch fixes:

  llvm/include/llvm/MC/MCRegisterInfo.h:146:7: error:
  'llvm::MCRegisterInfo' has virtual functions but non-virtual
  destructor [-Werror,-Wnon-virtual-dtor]

  llvm/lib/Target/NVPTX/NVPTXRegisterInfo.cpp:163:21: error:
  comparison of integers of different signs: 'int' and 'size_type'
  (aka 'unsigned long') [-Werror,-Wsign-compare]
Need to use the number of scalars, not the vector factor of the node.
Otherwise incorrect casting can be estimated, leading to a compiler
crash.
@jorickert jorickert self-requested a review January 9, 2025 15:56
@mgehre-amd mgehre-amd merged commit 9f349ee into feature/fused-ops Jan 10, 2025
5 checks passed
@mgehre-amd mgehre-amd deleted the bump_to_be6aed90 branch January 10, 2025 13:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.