I'm writing a llvm back-end, I'm meeting a problem for branch conditional instruction.
I want to translate the llvm IR branch to my specific target. below is what i have tried.
here is the llvm ir
%6 = icmp slt i32 %4, %5
br i1 %6, label %7, label %14
I have defined the instruction and instruction pattern, and i have write the compare instruction and pattern:
def BNE: InstToy<4, (outs), (ins GPR32:$Rd,btargetS15:$S15), "bne\t$Rd, $S15", [(brcond GPR32:$Rd, bb:$S15)]> {
bits<15> S15;
bits<5> Rd;
let Inst{19-5} = S15;
let Inst{4-0} = Rd;
}
The BNE instruction is check the Rd is zero, if no, it will jump to the target pc, otherwise do noting.
And i set "Legal" at isellowering
setOperationAction(ISD::BRCOND, MVT::i32, Legal);
but once i try the command compile the llvm ir
llc test.ll
it will raise the error:
llc: MachineBasicBlock.cpp:59: llvm::MCSymbol* llvm::MachineBasicBlock::getSymbol() const: Assertion `getNumber() >= 0 && "cannot get label for unreachable MBB"' failed.
I expect it can compiler without exception.
with -print-after-all on in llc, i found out the MBB disappears after branch folding pass, I found there is an error in analyzeBranch, after fixed that, the problem is fixed.
Related
I have a function in Julia that requires to do things in a loop. A parameter is passed to the loop, and the bigger this parameter, the slower the function gets. I would like to have a message to know in which iteration it is, but it seems that Julia waits for the whole function to be finished before printing anything. This is Julia 1.4. That behaviour was not on Julia 1.3.
A example would be like this
function f(x)
rr=0.000:0.0001:x
aux=0
for r in rr
print(r, " ")
aux+=veryslowfunction(r)
end
return aux
end
As it is, f, when called, does not print anything until it has finished.
You need to add after the print command:
flush(stdout)
Explanation
The standard output of a process is usually buffered. The particular buffer size and behavior will depend on your system setting and perhaps the terminal type.
By flushing the buffer you make sure that the contents is actually sent to the terminal.
Alternatively, you can also use a library like ProgressLogging.jl (needs TerminalLoggers.jl to see actual output), or ProgressMeter.jl, which will automatically update a nicely formatted status bar during each step of the loop.
For example, with ProgressMeter, a call to
function f(x)
rr=0.000:0.0001:x
aux=0
#showprogress for r in rr
aux += veryslowfunction(r)
end
return aux
end
will show something like (in the end):
Progress: 100%|██████████████████████████████████████████████████████████████| Time: 0:00:10
Again I can't reproduce the behaviour in my terminal (it always prints), but I wanted to add that for these types of situations the #show macro is quite neat:
julia> function f(x)
rr=0.000:0.0001:x
aux=0
for r in rr
#show r
aux+=veryslowfunction(r)
end
return aux
end
f (generic function with 1 method)
julia> f(1)
r = 0.0
r = 0.0001
r = 0.0002
...
It uses println under the hood:
julia> using MacroTools
julia> a = 5
5
julia> prettify(#expand(#show a))
quote
Base.println("a = ", Base.repr($(Expr(:(=), :ibex, :a))))
ibex
end
I'm trying to compile libpd to javascript or webassembly using emscripten sdk. According to some docs, if there is a Makefile, it can be compiled by using emmake make, (emconfigure is not used because there is no ./configure file), but I get the following error:
/home/ian/Documents/emsdk/emscripten/1.37.37/emcc.py -DPD -DHAVE_UNISTD_H -DUSEAPI_DUMMY -I./pure-data/src -I./libpd_wrapper -I./libpd_wrapper/util -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -fPIC -I"/usr/lib/jvm/default-java/include/linux" -DHAVE_LIBDL -ffast-math -funroll-loops -fomit-frame-pointer -O3 -DLIBPD_EXTRA -c -o pure-data/src/d_array.o pure-data/src/d_array.c
pure-data/src/d_array.c:523:2: error: No byte order defined
#error No byte order defined
^
1 error generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
<integrado>: fallo en las instrucciones para el objetivo 'pure-data/src/d_array.o'
make: *** [pure-data/src/d_array.o] Error 1
Any ideas? Do you think is possible to compile this library?
UPDATE: After tweaking every complaining file as suggested in #zakki 's answer
I get another error:
libpd_wrapper/util/ringbuffer.c:18:12: fatal error: 'stdatomic.h' file not found
#include <stdatomic.h>
That file have this content:
#if __STDC_VERSION__ >= 201112L // use stdatomic if C11 is available
#include <stdatomic.h> // HERE IS WHERE ERROR GOES
#define SYNC_FETCH(ptr) atomic_fetch_or((_Atomic int *)ptr, 0)
#define SYNC_COMPARE_AND_SWAP(ptr, oldval, newval) \
atomic_compare_exchange_strong((_Atomic int *)ptr, &oldval, newval)
//Some other definitions that I didn't put here
I read some threads some time ago about this problem with C++11, how can i fix this?
UPDATE 2: After adding && !defined(__EMSCRIPTEN__) now is able to compile, but I'm getting this warning that I don't understand:
WARNING:root:Dynamic libraries (.so, .dylib, .dll) are currently not
supported by Emscripten. For build system emulation purposes,
Emscripten will now generate a static library file (.bc) with the
suffix '.so'. For best practices, please adapt your build system to
directly generate a static LLVM bitcode library by setting the output
suffix to '.bc.')
Emscripten has endian.h. So add defined(__EMSCRIPTEN__) to ifdef.
#if defined(__linux__) || defined(__CYGWIN__) || defined(__GNU__) || \
defined(ANDROID) || defined(__EMSCRIPTEN__)
#include <endian.h>
#endif
Second, it seems like Emscripten bug.
#if __STDC_VERSION__ >= 201112L && !defined(__EMSCRIPTEN__)
Based on this figure, executing the SW instruction would cause these values to be assigned to the signals labeled in blue:
RegWrite = 0
ALUSrc = 1
ALU operation = 0010
MemRead = 0
MemWrite = 1
MemtoReg = X
PCSrc =
However, I am a little confused which inputs will be used in the Registers block? Can anyone describe the overall SW procedure in the MIPS datapath?
The execution of sw would follow the following steps in your diagram:
Instruction is read and decoded from the PC in the Instruction Memory subcircuit.
The register file is read for $rs and $rt (Registers subcircuit)
The value of $rs is added to the sign extended immediate (selected by ALUSrc) (ALU subcircuit).
The added value and $rt are passed to the Data Memory subcircuit where the value of $rt is written to memory.
I am attempting to use PGFortran for CUDA. I installed PGFortran on my computer and linked everything up to the best of my knowledge. To get going I decided to follow a tutorial listed here. When trying to compile the code:
module mathOps
contains
attributes(global) subroutine saxpy(x, y, a)
implicit none
real :: x(:), y(:)
real, value :: a
integer :: i, n
n = size(x)
i = blockDim%x * (blockIdx%x - 1) + threadIdx%x
if (i <= n) y(i) = y(i) + a*x(i)
end subroutine saxpy
end module mathOps
program testSaxpy
use mathOps
use cudafor
implicit none
integer, parameter :: N = 40000
real :: x(N), y(N), a
real, device :: x_d(N), y_d(N)
type(dim3) :: grid, tBlock
tBlock = dim3(256,1,1)
grid = dim3(ceiling(real(N)/tBlock%x),1,1)
x = 1.0; y = 2.0; a = 2.0
x_d = x
y_d = y
call saxpy<<<grid, tblock="">>>(x_d, y_d, a)
y = y_d
write(*,*) 'Max error: ', maxval(abs(y-4.0))
end program testSaxpy
I got:
PGF90-S-0034-Syntax error at or near identifier saxpy (main.cuf: 29)
0 inform, 0 warnings, 1 severes, 0 fatal for testsaxpy
The error points to the line call saxpy<<<grid, tblock="">>>(x_d, y_d, a). For some reason it apparently hates the fact that I am using <<< and >>>? Going by the tutorial those triple chevrons are meant to be there:
The information between the triple chevrons is the execution
configuration, which dictates how many device threads execute the
kernel in parallel.
Removing these chevrons would not make any sense since they are the purpose of the program. So why does PGFortran dislike this?
As for the compilation. I have followed the tutorial by using
pgf90 -o saxpy main.cuf. But since that gave an error I also tried pgf90 -Mcuda -o saxpy main.cuf. Same results.
There does seem to be a text error in that blog at the kernel invocation line:
call saxpy<<<grid, tblock="">>>(x_d, y_d, a)
tblock="" is not correct. You'll notice elsewhere in that blog text, the kernel invocation line is given correctly as:
call saxpy<<<grid,tBlock>>>(x_d, y_d, a)
So if you change that line accordingly in your actual code, I think you'll have better results.
I have a very short test file:
let print_backtrace () = try raise Not_found with
Not_found -> Printexc.print_backtrace stdout;;
let f () = print_backtrace (); Printf.printf "this is to make f non-tail-recursive\n";;
f ();
I compile and run:
% ocamlc -g test.ml
% OCAMLRUNPARAM=b ./a.out
Raised at file "test.ml", line 1, characters 35-44
this is to make f non-tail-recursive
Why isn't f listed in the stack trace? How can I write a function that will print a stack trace of the location it's called from?
The documentation for Printexc.print_backtrace says:
The backtrace lists the program locations where the most-recently raised exception was raised and where it was propagated through function calls.
It actually seems to be doing the right thing. The exception hasn't been propagated back through f.
If I move the call to Printexc.print_backtrace outside the call to f, I see a full backtrace.
$ cat test2.ml
let print_backtrace () = raise Not_found
let f () = let res = print_backtrace () in res ;;
try f () with Not_found -> Printexc.print_backtrace stdout
$ /usr/local/ocaml312/bin/ocamlc -g test2.ml
$ OCAMLRUNPARAM=b a.out
Raised at file "test2.ml", line 1, characters 31-40
Called from file "test2.ml", line 3, characters 21-39
Called from file "test2.ml", line 5, characters 4-8
Here is the code to do what I suggested. I recommend using ocamldebug if at all possible, this code is much too tricky. But it works on my system for this simple example.
let print_backtrace () =
match Unix.fork () with
| 0 -> raise Not_found
| pid -> let _ = Unix.waitpid [] pid in ()
let f () =
begin
print_backtrace ();
Printf.printf "after the backtrace\n";
end
;;
f ()
Here is a test run.
$ /usr/local/ocaml312/bin/ocamlc unix.cma -g test3.ml
$ OCAMLRUNPARAM=b a.out
Fatal error: exception Not_found
Raised at file "test3.ml", line 3, characters 17-26
Called from file "test3.ml", line 8, characters 4-22
Called from file "test3.ml", line 14, characters 0-4
after the backtrace
I realized that because of the uncaught exception, you don't really have any control over the way the child process exits. That's one reason this code is much too tricky. Please don't blame me if it doesn't work for you, but I hope it does prove useful.
I tested the code on Mac OS X 10.6.8 using OCaml 3.12.0.
Best regards,