tobiasBora has quit [Quit: Konversation terminated!]
wolfnn has quit [Ping timeout: 272 seconds]
jonludlam has quit [Remote host closed the connection]
mzie has quit [Quit: Page closed]
strobegen has joined #ocaml
julien_t has joined #ocaml
strobegen has quit [Quit: Leaving.]
NoNNaN has quit [Remote host closed the connection]
Arsenik has quit [Remote host closed the connection]
oriba has joined #ocaml
oriba has quit [Quit: oriba]
oriba has joined #ocaml
oriba has quit [Client Quit]
mfp has quit [Ping timeout: 246 seconds]
BitPuffin has quit [Ping timeout: 272 seconds]
Simn has quit [Read error: Connection reset by peer]
gnuvince has joined #ocaml
gnuvince has quit [Changing host]
gnuvince has joined #ocaml
julien_t has quit [Ping timeout: 246 seconds]
platypine has quit [Ping timeout: 245 seconds]
wagle has joined #ocaml
pango__ has joined #ocaml
pango_ has quit [Ping timeout: 245 seconds]
chambart has quit [Ping timeout: 252 seconds]
platypine has joined #ocaml
Drup has quit [Quit: Leaving.]
<whitequark>
I wonder how good ocamlopt actually is, is there an overview of the optimizations it performs somewhere?
<whitequark>
or just the source?
breakds has quit [Remote host closed the connection]
mcclurmc has joined #ocaml
talzeus has joined #ocaml
zxqdms has joined #ocaml
osa1_ has quit []
osa1 has joined #ocaml
strobegen has joined #ocaml
mcclurmc has quit [Quit: Leaving.]
gnuvince has quit [Ping timeout: 240 seconds]
kizzx2 has quit [Ping timeout: 272 seconds]
ygrek has joined #ocaml
kizzx2 has joined #ocaml
yacks has quit [Read error: Connection reset by peer]
shinnya has quit [Ping timeout: 246 seconds]
ygrek has quit [Ping timeout: 272 seconds]
xenocons has quit [Quit: leaving]
Kakadu has joined #ocaml
ggole has joined #ocaml
ygrek has joined #ocaml
ollehar has quit [Ping timeout: 272 seconds]
mfp has joined #ocaml
julien_t has joined #ocaml
ygrek_ has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
platypine has quit [Ping timeout: 240 seconds]
<adrien>
whitequark: it makes almost no optimization
<adrien>
inlining
<adrien>
the most particular thing it does is to emit "sane" asm
Simn has joined #ocaml
ulfdoz has joined #ocaml
ygrek_ has quit [Ping timeout: 240 seconds]
wolfnn has joined #ocaml
AltGr has joined #ocaml
<whitequark>
adrien: I see.
<whitequark>
I've been idly thinking whether Obj.magic inhibits optimizations by allowing the compiler to make less assumptions about the code.
<whitequark>
Seems like there aren't any to begin with.
<adrien>
well, the code that gets generated is already fairly good; it's difficult to improve it
<adrien>
you can introduce bugs, regressions on other platforms, there's increased complexity in the compiler, ...
yezariaely has joined #ocaml
<adrien>
if you compare GCC and OCaml, there are almost no incorrect code generation for the ocaml compiler
Snark has joined #ocaml
<mrvn>
What is realy ugly is that gcc uses undefined behaviour to optimize instead of giving a warning or error. So if you have some small bug somewhere whole parts of your code suddenly just disapear.
<adrien>
not in 4.9 :P
<mrvn>
they reverted that?
<mrvn>
4.8 had it majorly.
<adrien>
no, they give warnings
<adrien>
there's something for that
<mrvn>
is it on by default?
<adrien>
which is one more reason to avoid having an old compiler for work =/
<mrvn>
(or in -W -Wall?)
<adrien>
I don't know
<whitequark>
mrvn: that's not gcc, that's just about every C compiler--undefined behavior is explicitly present in the standard for the purpose of stronger optimization.
<adrien>
I don't think it would be by default
<adrien>
also, -Wall, -Wextra: -Wall includes -W
<mrvn>
whitequark: char s[10]; for(int i = 0; i < 10; ++i) { ... do something important ... s[i+1] = s[i]; }
<mrvn>
whitequark: gcc 4.8 will remove the whole loop silently.
<whitequark>
unfortunately there is no way to statically prove that the C program doesn't invoke UB at runtime, so just about only way to reliably detect breakage is to use tools like ubsan.
<whitequark>
mrvn: I know. that's legal.
<mrvn>
whitequark: it still totaly stupid
<mrvn>
It obviously never ever what the user ment.
<adrien>
well, if it took them only one minor release to move from that to emitting a warning, I'm fine
<mrvn>
Imho that is an error.
<whitequark>
mrvn: it is. the compiler really should emit a warning when the function does not have any defined behavior at all.
<adrien>
it's also incorrect code that makes no sense
<whitequark>
it can be very tricky to do in practice though.
<mrvn>
whitequark: no. it is verry easy.
<mrvn>
They already detected the undefined behaviour or they couldn't optimize it away. That was the hard part. It is trivial to give an error instead.
<whitequark>
mrvn: using undefined behavior for optimization is, in general, completely legal and sometimes desirable.
<mrvn>
whitequark: i never said it isn't legal. I said it is stupid.
<whitequark>
as per why it's tricky, well, it's hard to generally produce a good error message.
<whitequark>
it's easy to emit a warning like "this function always invokes UB", yes.
<adrien>
the information needs to flow from the optimization passes to the user
<whitequark>
the hard part is to explain to the user why exactly that happens.
<adrien>
there's clearly work involved in doing so
<mrvn>
whitequark: true. so start with being wague about it.
<jpdeplaix>
gasche: hey, there is something for you on cumulus (in the comments) :)
<mrvn>
whitequark: shouldn't be to hard to say "array out of bounce deteced in line xyz"
<mrvn>
bounds even
<whitequark>
mrvn: only if you keep that kind of high-level information in the IR
<whitequark>
that is very expensive
<whitequark>
clang's ubsan (which you need to turn on explicitly) does just that, and it catches all undefined behavior. gcc integrated it recently.
<mrvn>
whitequark: they already do at least for some parts. For example the warning that a function doesn't return anything.
<whitequark>
mrvn: that you can do with just the AST
<mrvn>
whitequark: That only shows with -O2 since it needs the optimizing step to detect it,.
<whitequark>
oh, I see.
<whitequark>
I'm not that familiar with GCC's IR so I cannot say how that works. I only looked into llvm/clang's implementation.
<mrvn>
anyway, all I'm saying is that it is stupid to just drop whole blocks of code just because one expression is undefined. Either give an error or hope it doesn't affect anything critical.
shinnya has joined #ocaml
<mrvn>
the former obviously would be better
<whitequark>
sure. this kind of bug also killed security-related checks in linux and chrome (pnacl), so it is pretty bad.
<whitequark>
in both cases silently resulting in exploitable code
julien_t has quit [Ping timeout: 248 seconds]
<whitequark>
I think UB is a design flaw in the language, but you have to work with what you have. *shrug*
<mrvn>
some UB you can't get around without becoming insane. Like under/overflow.
<whitequark>
turns out C's exploiting undefinedness of signed overflow in order to make tight loops faster by assuming they never roll over.
<whitequark>
insane, indeed.
<mrvn>
Plus on any still in use hardware the behaviour is well defined.
<mrvn>
whitequark: for(short i = 0; i < 65535; i += 2) { }
<mrvn>
whitequark: What is that supposed to do? catch the overflow and then end the loop?
<mrvn>
s/65535/32767/
<whitequark>
mrvn: um? what I mean is that the compiler can infer that the loop never rolls over, and that fact exposes more optimization opportunities for it.
<whitequark>
I don't know for sure but I think e.g. vectorization would benefit from it.
<mrvn>
more knowledge usualy gives better optimization
<whitequark>
it's an incredibly perverse way of gathering that knowledge, though. originally that was meant to support non-2's-complement architectures, I think.
<mrvn>
does the compiler even infere that? Doesn't it just say: 1) it doesn't overflow and we can optimize like this, or 2) it overflows and the behaviour is undefined so we can do whatever we want.
<whitequark>
UB means "there's an invariant you cannot observe which results in no overflow". for your empty case there is clearly no such invariant so it breaks. if you take a non-trivial example,
<whitequark>
e.g. replace the limit with a variable, this kind of analysis becomes more useful.
<whitequark>
so if you do "i < x", it infers that x can never dynamically be 32767.
darkf has quit [Quit: Leaving]
BitPuffin has joined #ocaml
<whitequark>
mrvn: let me in fact check if clang infers that.
ontologiae has joined #ocaml
<whitequark>
mrvn: it does, if I remove sign-extension caused by integer promotion in the comparison.