Author: Adrian Prantl
Date: 2024-08-27T14:52:56-07:00
New Revision: f2f78b284bfb9a118b1cc61202456004922e6ac7
URL:
https://github.com/llvm/llvm-project/commit/f2f78b284bfb9a118b1cc61202456004922e6ac7
DIFF:
https://github.com/llvm/llvm-project/commit/f2f78b284bfb9a118b1cc61202456004922e6ac7.diff
Author: Adrian Prantl
Date: 2024-08-27T15:25:32-07:00
New Revision: d48b0f8db8b9414e965a2d7c716e8ac44b2f291e
URL:
https://github.com/llvm/llvm-project/commit/d48b0f8db8b9414e965a2d7c716e8ac44b2f291e
DIFF:
https://github.com/llvm/llvm-project/commit/d48b0f8db8b9414e965a2d7c716e8ac44b2f291e.diff
Author: Adrian Prantl
Date: 2024-08-27T15:25:32-07:00
New Revision: 47667ee23d148458ab1c6f2c4cdce65ec981d766
URL:
https://github.com/llvm/llvm-project/commit/47667ee23d148458ab1c6f2c4cdce65ec981d766
DIFF:
https://github.com/llvm/llvm-project/commit/47667ee23d148458ab1c6f2c4cdce65ec981d766.diff
slydiman wrote:
> It also reads the memory in bulk (up to 1MB)
```
// Maximum number of bytes read (and buffered). We need to read at least
// `size` bytes for a successful match.
const size_t max_read_size = std::max(size, 0x1);
```
It seems the minimal chunk is 64KB and the maximal chunk m
Author: Adrian Prantl
Date: 2024-08-27T15:43:12-07:00
New Revision: de687eac24a3f4bac8b5ff9975f51ab98775f2d5
URL:
https://github.com/llvm/llvm-project/commit/de687eac24a3f4bac8b5ff9975f51ab98775f2d5
DIFF:
https://github.com/llvm/llvm-project/commit/de687eac24a3f4bac8b5ff9975f51ab98775f2d5.diff
Author: Adrian Prantl
Date: 2024-08-27T15:52:04-07:00
New Revision: d22bee143f4a1d867103571e23c992bf97f8e4b3
URL:
https://github.com/llvm/llvm-project/commit/d22bee143f4a1d867103571e23c992bf97f8e4b3
DIFF:
https://github.com/llvm/llvm-project/commit/d22bee143f4a1d867103571e23c992bf97f8e4b3.diff
https://github.com/clayborg commented:
LGTM. I will let others chime in.
https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low,
lldb::addr_t high,
if (region_size < size)
return LLDB_INVALID_ADDRESS;
+ // See "Boyer-Moore string search algorithm".
std::vector bad_char_heuristic(256, size);
- ProcessMemoryIterator i
jurahul wrote:
I did 2 sets of experiments, but data wise I am inconclusive if this causes a
real compile time regression.
1. Build MLIR verbose and capture all mlir-gen command lines to a file:
ninja -C build check-mlir --verbose | tee build_log.txt
grep "NATIVE/bin/mlir-tblgen " build_l
Author: Michael Buch
Date: 2024-08-28T00:40:12+01:00
New Revision: 0b1c8fd162aa1be66332d57d7da68416a9acb5ef
URL:
https://github.com/llvm/llvm-project/commit/0b1c8fd162aa1be66332d57d7da68416a9acb5ef
DIFF:
https://github.com/llvm/llvm-project/commit/0b1c8fd162aa1be66332d57d7da68416a9acb5ef.diff
Author: Adrian Prantl
Date: 2024-08-27T17:02:49-07:00
New Revision: 6ae657b08d624f9634fa6ebbf5d6fd7a22dc3b4d
URL:
https://github.com/llvm/llvm-project/commit/6ae657b08d624f9634fa6ebbf5d6fd7a22dc3b4d
DIFF:
https://github.com/llvm/llvm-project/commit/6ae657b08d624f9634fa6ebbf5d6fd7a22dc3b4d.diff
joker-eph wrote:
Having this enabled guarded by NDEBUG seems like a good option. There is
already some things already like this isn't there? I kind of remember that
using imbalanced `{` / `}` pair of something like that was checked only in
assert builds?
https://github.com/llvm/llvm-project/p
Author: Adrian Prantl
Date: 2024-08-27T17:25:17-07:00
New Revision: 32abe5d49b758edef0f0c19090361a6fe85c4092
URL:
https://github.com/llvm/llvm-project/commit/32abe5d49b758edef0f0c19090361a6fe85c4092
DIFF:
https://github.com/llvm/llvm-project/commit/32abe5d49b758edef0f0c19090361a6fe85c4092.diff
DmT021 wrote:
> What happens if we stop preferring the external symbols over internal ones in
> IRExecutionUnit::FindInSymbols? What tests break?
It looks like there are no failing tests.
https://github.com/llvm/llvm-project/pull/102835
___
lldb-comm
clayborg wrote:
> > What happens if we stop preferring the external symbols over internal ones
> > in IRExecutionUnit::FindInSymbols? What tests break?
>
> It looks like there are no failing tests.
We should always prefer symbols from the current module first, probably
external first, then fa
jurahul wrote:
Yeah. For the unbalanced {{ I actually committed a change to fail in
release builds as well by printing an error message as formatv() output.
The only issue with debug only is that many folks build tablegen in release
mode, so those bad uses may not get flagged. But as long as the
DmT021 wrote:
> We should always prefer symbols from the current module first, probably
> external first, then fall back to internal. If we do a search of all modules,
> we should prefer external symbols first and then internal, but only if they
> are unique.
So it's `current module external,
AlexeyMerzlyakov wrote:
@DavidSpickett, thank you for the review and sorry for late reply, I've just
returned from the BT w/o an access to my main PC.
Yes, the way to handle the register sets is pretty similar that ARM64 is using
in dynamic model (if I understand it correctly), so all further
https://github.com/AlexeyMerzlyakov edited
https://github.com/llvm/llvm-project/pull/104547
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DmT021 wrote:
Nope, `LoadAddressResolver` has its own logic about `eSymbolTypeUndefined` that
doesn't match `FindBestGlobalDataSymbol`. And it breaks
`TestWeakSymbols.TestWeakSymbolsInExpressions.test_weak_symbol_in_expr`.
At this point, I think it would be wiser to return to the original patch
clayborg wrote:
Don't let us hold this patch up if returning the the original patch that fixes
things makes things work if you can't easily get the same functionality from
this version of the patch. Will one part of this patch work with the new stuff
and the other part not? If so, maybe we all
clayborg wrote:
Let me know what you think of my idea to always just show the load address of
any SBValue. I think that is the best for LLDB, but I am open to opinions.
https://github.com/llvm/llvm-project/pull/104317
___
lldb-commits mailing list
lld
https://github.com/lhames closed
https://github.com/llvm/llvm-project/pull/106034
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Lang Hames
Date: 2024-08-28T15:36:57+10:00
New Revision: 3c5ab5a75a9c8fb87dcb13cdf4207aa975fd6972
URL:
https://github.com/llvm/llvm-project/commit/3c5ab5a75a9c8fb87dcb13cdf4207aa975fd6972
DIFF:
https://github.com/llvm/llvm-project/commit/3c5ab5a75a9c8fb87dcb13cdf4207aa975fd6972.diff
LO
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`cross-project-tests-sie-ubuntu-dwarf5` running on `doug-worker-1b` while
building `lldb` at step 5 "build-unified-tree".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/163/builds/4286
Here is the re
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`cross-project-tests-sie-ubuntu` running on `doug-worker-1a` while building
`lldb` at step 5 "build-unified-tree".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/181/builds/4140
Here is the relevant
Author: Lang Hames
Date: 2024-08-28T15:49:40+10:00
New Revision: e6cbea11578f197589801297d22b9b3bc4f1bd10
URL:
https://github.com/llvm/llvm-project/commit/e6cbea11578f197589801297d22b9b3bc4f1bd10
DIFF:
https://github.com/llvm/llvm-project/commit/e6cbea11578f197589801297d22b9b3bc4f1bd10.diff
LO
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `publish-sphinx-docs`
running on `as-worker-4` while building `lldb` at step 5
"build-docs-llvm-html-docs-clang-html-docs-clang-tools-html-docs-lld-html-docs-lldb-html-docs-flang-html-docs-openmp-html-docs-polly-html".
Full det
101 - 129 of 129 matches
Mail list logo
