nikic wrote:
@htyu LLVM does not support this. Support for doing that was officially removed
about ten years ago when data layout became mandatory, but even prior to that
IR was already target-specific, e.g. due to target-specific ABI. I think some
parts of MLIR may support this, but
htyu wrote:
> @karthik-man LLVM _always_ requires a correct data layout. Yes, that includes
> InstCombine.
What sort of correct data layout should be used if we are optimization
machine-independently? Like cross-compilation with `Clang -O3 -emit-llvm` , but
optimized the generated IR for
nikic wrote:
@karthik-man LLVM *always* requires a correct data layout. Yes, that includes
InstCombine.
https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
karthik-man wrote:
I am debugging a Triton issue
(https://github.com/triton-lang/triton/issues/4060), where an {i32, i32, i32,
i64} struct passed to _vprintf_ is printing the wrong value for the i64. The
issue here seems to be that Triton creates a llvm:Module with a default
DataLayout. In
nikic wrote:
@sgundapa Hm, I think the problem may be that while
https://github.com/llvm/llvm-project/pull/90802 removes the limitation on the
element types, it's still limited to single-index GEPs, while here there are
multiple indices. (Assuming this is related to swapping the GEPs at all,
sgundapa wrote:
> @sgundapa Does #90802 fix the issue you're seeing?
Unfortunately no.
https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
nikic wrote:
@sgundapa Does https://github.com/llvm/llvm-project/pull/90802 fix the issue
you're seeing?
https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
sgundapa wrote:
I've observed a significant regression in one of the AMDGPU benchmarks after
applying this patch. The base address calculation within the unrolled loop
seems to be the source. I've attached "before.log" and "after.log" files that
detail the issue.
The modified GEP format,
Prabhuk wrote:
> I am debugging an assertion failure regression in one of our projects that
> uses the FlatMap data structure implemented here:
>
> https://pigweed.googlesource.com/pigweed/pigweed/+/refs/heads/main/pw_containers/public/pw_containers/flat_map.h#180
>
> The regression was that
Prabhuk wrote:
I am debugging an assertion failure regression in one of our projects that uses
the FlatMap data structure implemented here:
https://pigweed.googlesource.com/pigweed/pigweed/+/refs/heads/main/pw_containers/public/pw_containers/flat_map.h#180
The regression was that the `find`
nikic wrote:
@Artem-B I've put up https://github.com/llvm/llvm-project/pull/80983 to address
this issue.
https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
dtcxzyw wrote:
Another example:
```
diff --git a/bench/hermes/optimized/Sorting.cpp.ll
b/bench/hermes/optimized/Sorting.cpp.ll
index 1a808c47..e03089ca 100644
--- a/bench/hermes/optimized/Sorting.cpp.ll
+++ b/bench/hermes/optimized/Sorting.cpp.ll
@@ -41,20 +41,22 @@ if.end:
nikic wrote:
@dtcxzyw GitHub can't display the diff, and struggles to clone the repo. Can
you share the diffs for just the mentioned files?
https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/fhahn approved this pull request.
LGTM, looks like a great first step! Will be interesting to see what kind of
regressions this surfaces (if any)
https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
14 matches
Mail list logo
