nunoplopes
Repos
5
Followers
76

Automatic verification of LLVM optimizations

385
43

A tracing JIT compiler for PyTorch

6
0

The Z3 Theorem Prover

8036
1221

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.

16149
5214

Events

attempt to fix cmake build

Created at 9 hours ago

Fix clang build (#6378)

Created at 16 hours ago
pull request closed
Naxaes/clang build fix

Fixed compilation bugs.

Added a missing parameter in iuc_solver constructor and fixed the error error: reference to local binding 'pivot' declared in enclosing function 'euf::res_proof_checker::clause' which was due to an error with structured bindings.

Created at 16 hours ago

fix build

Created at 18 hours ago

fix #850: removing unreachable BBs didn't account for phis with multiple entries from same BB

Created at 1 day ago
closed issue
crash bug

this command:

/home/regehr/llvm-project/for-alive/bin/clang -O2 -c test.c -mllvm -tv-disable-undef-input -mllvm -tv-disable-poison-input -fno-strict-aliasing -mllvm -enable-global-analyses=0 -fpass-plugin=/home/regehr/alive2-regehr/build/tv/tv.so -Xclang -load -Xclang /home/regehr/alive2-regehr/build/tv/tv.so

on this input:

int a;
int b(int c) {
  switch (c) {
  case 0:
    return a == 10 || a == 3 || a;
  case 48:
  case 32:
  case 16:
    return a;
  }
}
int d;
int e() {
  switch (d) {
  case 0:
  case 48:
    return 0;
  case 32:
  case 16:
    return b(d);
  }
}

terminates throwing a std::out_of_range

Created at 1 day ago

remove tabs

Created at 2 days ago
pull request closed
just a few quality-of-life improvements
  • one file from PHP uses like 240 GB of disk space for its log file even in quiet mode because we're printing its initializers which are massive, this suppresses that. this is a one-off fix but it's easy to generalize it if we need it in other locations, but not doing that yet since we've gotten pretty far without this
  • I'm always adding a "return" into the main TV function for debugging purposes that avoid doing the actual TV part, here we add a command line flag for this so I don't have to modify the code
  • append a bit of extra random stuff to dumped bitcode files to they don't tend to overwrite each other
Created at 2 days ago

just a few quality-of-life improvements (#852)

Created at 2 days ago

use std streams instead of LLVM's

Created at 3 days ago

avoid using LLVM's CloneModule (#848)

Created at 3 days ago
pull request closed
avoid using LLVM's CloneModule

let's just avoid using CloneModule, not only is it slow and leaky, but also it contains a couple of correctness bugs

Created at 3 days ago

Update tv.cpp

Created at 3 days ago
issue comment
Fails on P6 architecture due to SSE2 usage

Can we have a separate issue for libz3 failing in a more user-friendly way on non-sse2+ systems? Such as the forcing the library init call to fail?

PRs welcome, but not issues as it's a pretty rare case and resources are limited.

Created at 3 days ago
closed issue
[Question] The fastest way to evaluate a constraint

Hi there,

May I ask what could be the fastest way to evaluate a constraint? The scenario I encountered is that, assuming I have a constraint (say C) and a concrete value (say 100) of a symbol (say a) in C, and I want to evaluate whether the concrete value 100 of the symbol a could make the constraint C true or false, i.e., sat or unsat.

Currently, my solution (using C++ APIs) is to encode the constraint a == 100 into C and invoke solver.check() to check the satisfiability of the new constraint C && (a == 100). Such a solution can work as intended but I found it's pretty slow---every time it needs to invoke check() to evaluate it. I have tried to find a faster way to do the evaluation but failed. Are there any other solutions that could make this evaluation faster, e.g., the one without calling the solver.check()?

Thanks and look forward to your suggestions.

Best regards, Haoxin

Created at 4 days ago
issue comment
[Question] The fastest way to evaluate a constraint

There's no way around calling check() for each concrete value. Unless you're lucky. For example, you can try to get a model just for C. If a is not in the model, then it's SAT for any a.

If you know a priori all the concrete values you care about, you can do: C && (a == 1 || a == 2 || ... ).

Then get a model. It has a=2, for example.

Then assert on the same solver a != 2.

Continue until it's unsat. You'll do n+1 queries, where n is the number of concrete values of a for which the formula is SAT. Plus, you'll be doing incremental solving without push/pop (that is slow).

Created at 4 days ago
closed issue
Fails on P6 architecture due to SSE2 usage

Having an Xorg startup failure on my Pentium Pro system because Xorg is using libz3, which is built with -mfpmath=sse -msse -msse2. There doesn't seem to be a straightforward way of instructing cmake to build libz3 without SSE instructions.

Starting program: /usr/lib/xorg/Xorg 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

X.Org X Server 1.21.1.4
X Protocol Version 11, Revision 0
Current Operating System: Linux ppro 5.19.0-2-686 #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1 (2022-09-24) i686
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.19.0-2-686 root=UUID=dbeee09d-4412-49ab-9c61-a0900452f978 ro apic=debug console=tty0 console=ttyS0,115200 earlyprintk=serial,ttyS0,115200 mitigations=off
xorg-server 2:21.1.4-2 (https://www.debian.org/support) 
Current version of pixman: 0.40.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Sep 26 15:14:33 2022
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
xf86TokenToOptinfo: table is NULL
xf86TokenToOptinfo: table is NULL

Program received signal SIGILL, Illegal instruction.
0xa95672de in ?? () from /lib/i386-linux-gnu/libz3.so.4
(gdb) bt
#0  0xa95672de in ?? () from /lib/i386-linux-gnu/libz3.so.4
#1  0xb7fcdd6b in call_init (env=0xbffff5dc, argv=0xbffff5d4, argc=1, l=<optimized out>) at ./elf/dl-init.c:70
#2  call_init (l=<optimized out>, argc=1, argv=0xbffff5d4, env=0xbffff5dc) at ./elf/dl-init.c:26
#3  0xb7fcde5c in _dl_init (main_map=<optimized out>, argc=1, argv=0xbffff5d4, env=0xbffff5dc) at ./elf/dl-init.c:117
#4  0xb7fd4d97 in call_dl_init (closure=0xbfffdee0) at ./elf/dl-open.c:485
#5  0xb79df934 in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized out>, args=<optimized out>) at ./elf/dl-error-skeleton.c:182
#6  0xb7fd4d25 in dl_open_worker (a=0xbfffe028) at ./elf/dl-open.c:808
#7  0xb79df8d7 in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized out>, args=<optimized out>) at ./elf/dl-error-skeleton.c:208
#8  0xb7fd50c0 in _dl_open (file=0xbfffe2ec "/usr/lib/i386-linux-gnu/dri/swrast_dri.so", mode=-2147483647, caller_dlopen=0xb74a2222, nsid=<optimized out>, argc=1, argv=0xbffff5d4, 
    env=0xbffff5dc) at ./elf/dl-open.c:886
#9  0xb78f9848 in dlopen_doit (a=0xbfffe28c) at ./dlfcn/dlopen.c:56
#10 0xb79df8d7 in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized out>, args=<optimized out>) at ./elf/dl-error-skeleton.c:208
#11 0xb79df9a0 in __GI__dl_catch_error (objname=0xbfffe244, errstring=0xbfffe248, mallocedp=0xbfffe243, operate=0xb78f97d0 <dlopen_doit>, args=0xbfffe28c)
    at ./elf/dl-error-skeleton.c:227
#12 0xb7fe1de8 in _rtld_catch_error (objname=0xbfffe244, errstring=0xbfffe248, mallocedp=0xbfffe243, operate=0xb78f97d0 <dlopen_doit>, args=0xbfffe28c)
    at ./elf/dl-error-skeleton.c:260
#13 0xb78f9297 in _dlerror_run (operate=<optimized out>, args=<optimized out>) at ./dlfcn/dlerror.c:138
#14 0xb78f9918 in dlopen_implementation (dl_caller=<optimized out>, mode=1, file=0xbfffe2ec "/usr/lib/i386-linux-gnu/dri/swrast_dri.so") at ./dlfcn/dlopen.c:71
#15 ___dlopen (file=0xbfffe2ec "/usr/lib/i386-linux-gnu/dri/swrast_dri.so", mode=1) at ./dlfcn/dlopen.c:81
#16 0xb74a2222 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#17 0xb74a1aad in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#18 0xb74a07ed in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#19 0x0044b9ab in _CallCallbacks ()
#20 0x0057fc24 in ?? ()
#21 0x004b9930 in InitExtensions ()
#22 0x0044a3e7 in ?? ()
#23 0x00432b2b in ?? ()
#24 0xb789b3b5 in __libc_start_call_main (main=main@entry=0x432b00, argc=argc@entry=1, argv=argv@entry=0xbffff5d4) at ../sysdeps/nptl/libc_start_call_main.h:58
#25 0xb789b47f in __libc_start_main_impl (main=0x432b00, argc=1, argv=0xbffff5d4, init=0x0, fini=0x0, rtld_fini=0xb7fcd930 <_dl_fini>, stack_end=0xbffff5cc)
    at ../csu/libc-start.c:389
#26 0x00432b67 in _start ()
Created at 4 days ago
issue comment
Fails on P6 architecture due to SSE2 usage

We need SSE math for correctness (for the FPA theory). You can't use an x86 chip that hasn't support for it.

I think the issue is why is Xorg using Z3? I guess it comes from Mesa, which links with LLVM, which optionally links with Z3 if available for the static analyzer. But I doubt Mesa or Xorg are using Z3, so this is a packaging problem.

Created at 4 days ago
closed issue
No support for Clang.

why saying that it support clang while the only thing i see is :

if (MSVC)
  set(CMAKE_CXX_FLAGS                "/GL /EHsc /W2 ${CMAKE_CXX_FLAGS}")
  set(CMAKE_CXX_FLAGS_DEBUG          "/Od /Zi ${CMAKE_CXX_FLAGS_DEBUG}")
  set(CMAKE_CXX_FLAGS_RELEASE        "/O2 /Oi /Oy /Zc:inline ${CMAKE_CXX_FLAGS_RELEASE}")
  set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "/O2 /Oi /Zi ${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")
  set(CMAKE_EXE_LINKER_FLAGS         "/LTCG:INCREMENTAL ${CMAKE_EXE_LINKER_FLAGS}")
else()
  set(CMAKE_CXX_FLAGS                "-Wall -Werror -march=native -fPIC ${CMAKE_CXX_FLAGS}")
  set(CMAKE_CXX_FLAGS_DEBUG          "-g -Og ${CMAKE_CXX_FLAGS_DEBUG}")
  set(CMAKE_CXX_FLAGS_RELEASE        "-O3 ${CMAKE_CXX_FLAGS_RELEASE}")
  set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELEASE} -g ${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")
endif()

it only supports gcc, even on VS it doesn't compile : resulting on an unknown Compiler error.

Created at 4 days ago
issue comment
No support for Clang.

It supports clang. We have buildbots running gcc & clang on every commit. MSVC is not tested and probably doesn't work. We never finished adding support for it. But we are open to PRs.

Created at 4 days ago
issue comment
question sum bitvec

All variables in a sum must be of the same type. You need to zero- or sign-extend the smaller variables or truncate the larger ones. Anyway, it's a good moment to pause and figure out the number of bits you need for the output to avoid overflows (if important).

Created at 5 days ago
closed issue
question sum bitvec
Created at 5 days ago
issue comment
-tv-save-ir slowly leaks memory in LLVM's cloneModule with debug metadata
  • revert #847
Created at 5 days ago

strip out flags that would cause clang to add debug info (#847)

Created at 5 days ago
pull request closed
strip out flags that would cause clang to add debug info
Created at 5 days ago
opened issue
-tv-save-ir slowly leaks memory in LLVM's cloneModule with debug metadata

We use LLVM's module cloning API with -tv-save-ir. This API gives us a copy of a module, but it shares the LLVMContext with the original module. So anything that uses structural identity will accumulate in the context.

The issue is that the debug metadata seems to be duplicated and not shared across the 2 modules. As LLVM doesn't do any GC on canonicalized metadata, we slowly "leak" memory.

The metadata nodes that are duplicated are:

MDTuple
DILocation
DILocalVariable
DISubroutineType
DISubprogram

I didn't trace it enough to understand why the duplication happens. Is the metadata dependent on the registers somehow? Can this leak build up on a regular LLVM build as well?

Created at 6 days ago

llvm2alive: optimize cleanup of created constexprs

Created at 1 week ago

shrink peak memory consumptio with -tv-save-ir

Created at 1 week ago