I would like to be able to specify LLVM meta-data from Rust directly, without having to generate LLVM-IR and play with that.

For example, whether a function/argument is readonly, readnone, etc.

Not that this improves codegen directly, but in some cases i think it would make it easier to diagnose codegen issues

eddyb: think i might have found my first measurable runtime perf change from this data cl.ly/1n2u362R0S0p/Screen%20Shot%202018-05-04%20at%202.17.23%20AM.png

anp: do you have the exact git commit hash or something?

same step down at 2/10/18 for instruction count, wall time

still getting there

these are just nightlies

takes foreverrrr to run so cant run on every commit

which nightly?

anp: I wonder if there's a way to do this visualization to draw some obvious lines

looks like 2/11?

yeah

i have plans

showing the "break"

anp: do you have the nightly around to query it?

for -vV?

id have to dl

or where can I get that info without downloading it?

but im on a fast connection

uh

nightlies.rs once i fix the service worker

lmao

oh and the lazy list scroll positions

and figure out a way to customize what targets/components/etc you want to see

oh this is backports

boo no nightly tags

this is in the rustup metadata, sec

eddyb: 45fba43b3d5b4d1944268cf973099bfacb11bf4c

I'm not seeing anything interesting

is the commit on this

anp: before or after?

after

and before ends at 3bcda48a30b21e46b81a7989deb30a3ba85fb918

okay thanks

np

its definitely possible that something about this machine changed

llvm 6?

yupp

I was literally typing that :P

lol

i'm not seeing that pattern on any other benchmarks yet and they run in groups (all benches for a nightly in a group, then the next nightly) so i don't expect this to be an environmental variation

and an llvm upgrade is a satisfying enough explanation

ok well its 230am here, off to bed, but wanted to remark on the first lolbench sighting (albeit a really obvious one from a really obvious cause :P)

anp: Nice!

rkruppe: I'm still confused about rust-lang/rust #49479#issuecomment-386594093

rkruppe: "The InlineAsm only directly compares the function type pointers, so it will only consider InlineAsm blocks to be the same if they have exactly the same function type." where is that in the code?

rkruppe: Oh, is that it? code.woboq.org/llvm/llvm/lib/IR/ConstantsContext.h.html#437

nox: yeah the interning decision is made based on the FunctionType equality

or at least so it seems

as i said i can't get what should be a nice clean repro to actually trigger this assertion

OH WAIT

maybe godbolt is without assertions?

Hah!

nox: try to run opt on it locally (your local build has llvm assertions enabled right)?

Not sure about that.

well try it

hopefully it just crashes and we'll have our answer :)

rkruppe: Didn't crash, but I'm pretty sure I don't have assertions enabled.

:'(

oh i have a rust build around, let me try

rkruppe: I have one too, but that doesn't build `opt` right?

it does!

.../llvm/bin/opt

that is, build/$triple/llvm/bin/opt

yeah it crashes for me

Neat!

rkruppe: So this is indeed an illegitimate assertion?

yeah

not sure what the right fix is (how does it handle the FunctionType for normal calls?) but something will have to change in llvm

What do you mean about normal calls?

presumably it doesn't just check the function signature for inline asm but also for everything else has that a signature

so it doesn't assert much there

Should it? I'm confused.

I feel like the fix is to just remove the assertion, no?

The assert is "just" a sanity check so sure it could be removed

but modulo the FunctionType problem it serves as an effective way to ensure FunctionComparator and InlineAsm uniquing are in agreement

in particular that FunctionComparator doesn't forget about any fields (which would lead to a miscompilation)

so it would be nice to be able to salvage it

but that is for upstream to worry about

someone with a bugs.llvm.org account needs to report this and we backport the fix

rkruppe: could replace with an assertion that L->getFunctionType() != R->getFunctionType()

That would make sure that this is the only case that can compare equal without being uniqued

nikic: Good idea.

rkruppe: Just sent an email to the Powers That Be to get an account, hah.

nikic: that doesn't quite achieve what i said (could have both different FunctionType and forgotten another field) but it's better than nothing i guess

rkruppe: If only that stuff could be derived. :)

nox: the monkey's paw curls and they generate that code... with tablegen

👍

nikic: Commented with your assertion suggestion just now, bugs.llvm.org/show_bug.cgi?id=37339#c1

rkruppe: What do you think of trying to land this in our own LLVM?

for moving forward with your pr we could just drop the assertion temporarily until an upstream bug fix (or use the one suggested by nikic, but not as important if it's temporary)

rkruppe: Ok.

rkruppe: It's apéro time though, so I'll do that later tonight or on Monday.

This working group is not the only new stuff in my life, started theatre last year and we have our first show tomorrow evening. :3

are the llvm.experimental.constrained... intrinsics new ?

they support different rounding modes

including a dynamic one, such that changing the rounding mode when these are used is not undefined behavior :o

gnzlbg: they’re been around for about a year

gnzlbg: yes those intrinsics are a major component of the plan for supporting #pragma STD FENV_ACCESS, i.e., anything that deviates from the default floating point environment

I’m not sure what the view is on using experimental intrinsics in rust?

we already use some

e.g. vector reductions

pushed the data and the notebook i'm using github.com/anp/lolbench-analysis

interesting read ^^ trent.me/is-prefix-of-string-in-table

oh, and dendibakh.github.io/blog/2018/04/03…for-microarchitectural-benchmarking

neato!

looks like the likwid-perfctr thing is rather similar to the criterion patches i wrote