@@ -1159,7 +1159,9 @@ class ARMOperand : public MCParsedAsmOperand {
if (!isImm()) return false;
const MCConstantExpr *CE = dyn_cast(getImm());
if (!CE) return false;
davemgreen wrote:
Can this check that CE->getActiveBits() > 32?
https://github.c
davemgreen wrote:
Rust
(https://github.com/rust-lang/rust/blob/79734f1db8dbe322192dea32c0f6b80ab14c4c1d/compiler/rustc_codegen_llvm/src/llvm_util.rs#L229)
and zig
(https://github.com/ziglang/zig/blob/44db92d1ca90c9cfdfb29fe46f04ff8f11c80901/lib/std/Target/aarch64.zig#L43)
are two examples of
davemgreen wrote:
@tmatheson-arm reached out and we have a bit of a conversation internally. I do
think that there is too much going on in this one pr to be sensible to review,
but from what I've looked at my main points I think are:
- Some AEK names get renamed in ways I would not expect them
davemgreen wrote:
> This is already split into 18 commits, I don't think there's any reason to
> split it into 18 PRs, since comments on one of them likely apply to the
> others.
I disagree. This is going to be awkward for a lot of users of llvm and contains
at least some details I don't agre
davemgreen wrote:
IMO This patch looks far too large to sensibly review and needs to be split up.
A lot of the changes don't really looks like mechanical renamings, and it is
hard to see how they would not break existing uses of llvm arch64 target
features?
https://github.com/llvm/llvm-projec
davemgreen wrote:
I see. The issue is that the opposite is often true as well - if we add a
target specific intrinsic for this then, whilst we get a single instruction
being emitted, we don't see all the other optimizations that the compiler can
and should be performing.
Things like constant
davemgreen wrote:
OK. We would not usually add intrinsics like this without a strong motivating
case, that could not be optimized in some other way. It is better to use target
independent options when available, and inline assembly is available as a
fallback if it is really needed. But I would
davemgreen wrote:
Hello. Can you explain why this is needed, as opposed to using the equivalent
shift/and/ors?
https://github.com/llvm/llvm-project/pull/79672
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
davemgreen wrote:
Thanks. It sounds like there are not a lot of code changes, which is a good
sign. I didn't expect the debug problems though.
I'll try and take a look at the patch. Perhaps you are right that we need a new
method for the debug info to use.
https://github.com/llvm/llvm-project
davemgreen wrote:
I don't believe the undef is the issue - I think the issue is that
AArch64InstrInfo::isCopyInstrImpl is saying that a W-reg orr is a copy, even if
it is really a zextend because the entire X output register is depended upon.
Can you try and add something to isCopyInstImpl ins
davemgreen wrote:
Hello. I think that if you removed undef from the first instruction the result
would still be incorrect. With:
```
$x8 = ORRXrs $xzr, $x0, 0, implicit $w0
$w8 = ORRWrs $wzr, $w0, 0, implicit-def $x8
```
The second instruction will zero-extend the w0 register to x8. It would be
davemgreen wrote:
Do you have any analysis on the expected magnitude of the inaccuracy we might
expect from performing the fdiv/trunc/fma vs the call to fmod?
https://github.com/llvm/llvm-project/pull/67642
___
lldb-commits mailing list
lldb-commits@l
12 matches
Mail list logo
