Outdated pointee-type phrasings in ABI attributes have been removed.

the extension enabled with xmipscbop.

Please refer "MIPS RV64 P8700/P8700-F Multiprocessing System
Programmer’s Guide" for more info on the extension at
https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf

Clarify lots of existing practice. Expand on the "major change" section,
which is the closest thing we have on how to run an RFC.

---------

Co-authored-by: Oleksandr "Alex" Zinenko <azinenko@amd.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>

Version 2 was added more than two years ago
(https://github.com/llvm/llvm-project/commit/6015a045d768feab3bae9ad9c0c81e118df8b04a).
So it should be safe to deprecate older versions.

In Vulkan, the signedness of the accesses to images has to match the
signedness of the backing image.
    
See

https://docs.vulkan.org/spec/latest/chapters/textures.html#textures-input,
where it says the behaviour is undefined if
    
> the signedness of any read or sample operation does not match the
signedness of the image’s format.
    
Users who define say an `RWBuffer<int>` will create a Vulkan image with
a signed integer format. So the HLSL that is generated must match that
expecation.
    
The solution we use is to generate a `spirv.SignedImage` target type for
signed integer instead of `spirv.Image`. The two types are otherwise the
same.
    
The backend will add the `signExtend` image operand to access to the
image to ensure the image is access as a signed image.
    
Fixes #144580

As a precaution until the issues reported (by me)
in https://github.com/llvm/llvm-project/issues/135208
are investigated.

Add handling for FPFastMathMode in SPIR-V shaders. This is a first pass
that
simply does a direct translation when the proper extension is available.
This will unblock work for HLSL. However, it is not a full solution.

The default math mode for spir-v is determined by the API. When
targeting Vulkan many of the fast math options are assumed. We should do
something particular when targeting Vulkan.

We will also need to handle the hlsl "precise" keyword correctly when
FPFastMathMode is not available.

Unblockes https://github.com/llvm/llvm-project/issues/140739, but we are
keeing it open to track the remaining issues mentioned above.

Add `dead_on_return` attribute, which is meant to be taken advantage
by the frontend, and states that the memory pointed to by the argument
is dead upon function return. As with `byval`, it is supposed to be
used for passing aggregates by value. The difference lies in the ABI:
`byval` implies that the pointer is explicitly passed as argument to
the callee (during codegen the copy is emitted as per byval contract),
whereas a `dead_on_return`-marked argument implies that the copy
already exists in the IR, is located at a specific stack offset within
the caller, and this memory will not be read further by the caller upon
callee return – or otherwise poison, if read before being written.

RFC: https://discourse.llvm.org/t/rfc-add-dead-on-return-attribute/86871.

This PR introduces support for the DWARF64 format, enabling handling of
64-bit DWARF sections as defined by the DWARF specification. The update
includes adjustments to header parsing and modification of form values
to accommodate 64-bit offsets and values.
Also Added the testcase to verify the DWARF64 format.

This is the implicit process but useful to spell it out I think. To give
folks more confidence in asking.

Inspired by
https://discourse.llvm.org/t/request-github-issue-triage-permission-for-labeling-clang-issues/87126/1