whitequark (whitequark)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 21 2013, 11:58 AM (226 w, 22 h)

Recent Activity

Fri, May 19

whitequark requested changes to D32368: LLVM C DIBuilder Creation APIs.
Fri, May 19, 12:39 PM

Thu, May 11

whitequark added a comment to D18738: Add new !unconditionally_dereferenceable load instruction metadata.

@hfinkel Oh, my bad--I now remember that this came up long ago...

Thu, May 11, 1:23 PM
whitequark added a comment to D18738: Add new !unconditionally_dereferenceable load instruction metadata.

I'd be okay (even happy! :) ) if you add a @llvm.safe.load.<ty> intrinsic that never has UB, and returns undef if the address passed to it is not dereferenceable. That intrinsic could then be marked speculatable. If needed, we could even implement the intrinsic by trying to read from the address passed in, and by catching the SIGSEGV or SIGBUS, if any.

Thu, May 11, 11:37 AM
D18738: Add new !unconditionally_dereferenceable load instruction metadata now requires changes to proceed.

@sanjoy Since D20116 is in, is there any reason to avoid having a !speculatable on load instructions? It can be emulated anyway by defining a class of @load.x functions marked speculatable and their return value dereferenceable, so there is no loss of soundness.

Thu, May 11, 6:50 AM

Apr 21 2017

whitequark added inline comments to D32368: LLVM C DIBuilder Creation APIs.
Apr 21 2017, 12:50 PM

Apr 19 2017

whitequark accepted D32122: Introduce LLVMDIBuilderRef.
Apr 19 2017, 2:13 PM

Apr 17 2017

whitequark added a comment to D32122: Introduce LLVMDIBuilderRef.

The real question is established bindings like the OCaml and python bindings -- would they be willing to use this API with breaking changes?

Apr 17 2017, 12:29 PM

Jan 25 2017

whitequark committed rL293041: Mark @llvm.powi.* as safe to speculatively execute..
Mark @llvm.powi.* as safe to speculatively execute.
Jan 25 2017, 1:43 AM

Jan 4 2017

whitequark accepted D28294: [cmake] Canonicalize CMake booleans to 0/1 for Python interop.

Seems good to me!

Jan 4 2017, 12:19 PM

Nov 12 2016

whitequark accepted D26580: [OCaml] Clear cross-target test deps when building out-of-tree.
Nov 12 2016, 6:46 AM

Nov 11 2016

whitequark committed rL286705: [OCaml] Adapt to the new attribute C API..
[OCaml] Adapt to the new attribute C API.
Nov 11 2016, 7:48 PM
whitequark committed rL286704: [C API] Fix several null pointer dereferences..
[C API] Fix several null pointer dereferences.
Nov 11 2016, 7:48 PM
whitequark added a comment to D18738: Add new !unconditionally_dereferenceable load instruction metadata.

@sanjoy OK, I understand now. In a nutshell, our disagreement was in whether dead code in IR can affect semantics of live code. This doesn't strike me as particularly bad (even after looking at your examples--clearly they shouldn't use !unconditionally_dereferenceable, but that doesn't mean it's not useful elsewhere), but you clearly have more experience here, so I won't argue that my approach is viable for upstream.

Nov 11 2016, 6:55 AM

Nov 10 2016

whitequark added a comment to D18738: Add new !unconditionally_dereferenceable load instruction metadata.

@sanjoy Your example is being transformed as expected, from my POV. The idea is that an unconditionally dereferenceable load cannot be moved across a store that may-alias the pointer, and this lets one initialize it safely. Other than immediately after allocation, a pointer which is ever loaded like that must always be dereferenceable.

Nov 10 2016, 12:46 PM
whitequark added a comment to D26501: [LICM] Retain load instruction invariant metadata when hoisting.

@hfinkel OK, I see. I wonder if the desired optimizations here as well as in D18738 could be more easily handled by loop peeling.

What do you mean? I don't see how loop peeling generally solves this hosting-out-of-nested-loops problem.

Nov 10 2016, 10:42 AM
whitequark added a comment to D26501: [LICM] Retain load instruction invariant metadata when hoisting.

@hfinkel OK, I see. I wonder if the desired optimizations here as well as in D18738 could be more easily handled by loop peeling.

Nov 10 2016, 10:33 AM
whitequark abandoned D2176: [llvm-c] Improve IR introspection.

Stale and no time to update in sight.

Nov 10 2016, 7:32 AM
whitequark updated the diff for D26501: [LICM] Retain load instruction invariant metadata when hoisting.

Actually updated the diff this time.

Nov 10 2016, 7:31 AM
whitequark updated the diff for D26501: [LICM] Retain load instruction invariant metadata when hoisting.

Loads of pointers are not hoisted for some reason, so keeping the pointer-related metadata makes no sense for now. Amended patch to be less aggressive and only keep !invariant.load.

Nov 10 2016, 7:30 AM
whitequark requested review of D18738: Add new !unconditionally_dereferenceable load instruction metadata.

The source level rule is as follows: I have a memory-safe language with region-based memory management. Once an object is constructed, pointers to it are guaranteed by the frontend to live no longer than the object. Thus, most* pointers constructed, even in dead code, can be dereferenced at any time when it is possible at all to construct it.

Nov 10 2016, 7:23 AM
whitequark retitled D26501: [LICM] Retain load instruction invariant metadata when hoisting from to [LICM] Retain load instruction metadata when hoisting.
Nov 10 2016, 6:57 AM

Oct 4 2016

whitequark committed rL283203: [SelectionDAG] Fix calling convention in expansion of ?MULO..
[SelectionDAG] Fix calling convention in expansion of ?MULO.
Oct 4 2016, 2:16 AM
whitequark closed D25223: [SelectionDAG] Fix calling convention in expansion of ?MULO. by committing rL283203: [SelectionDAG] Fix calling convention in expansion of ?MULO..
Oct 4 2016, 2:16 AM

Oct 3 2016

whitequark updated the diff for D25223: [SelectionDAG] Fix calling convention in expansion of ?MULO..

Added explanatory comment

Oct 3 2016, 11:54 PM
whitequark added a comment to D25223: [SelectionDAG] Fix calling convention in expansion of ?MULO..

Maybe ppc32 big endian for the testcase?

Oct 3 2016, 9:24 PM
whitequark updated D25223: [SelectionDAG] Fix calling convention in expansion of ?MULO..
Oct 3 2016, 9:08 PM
whitequark added a comment to D25223: [SelectionDAG] Fix calling convention in expansion of ?MULO..

It is quite regretful that this change comes without tests, but I wasn't able to trick any of the existing in-tree bi-endian backends into generating a __muldi3 sequence that I need to match against. Even worse, just unconditionally swapping the registers doesn't break any of the tests, implying that this branch wasn't tested in the first place (and also that there's nothing I can easily modify).

Oct 3 2016, 9:02 PM
whitequark retitled D25223: [SelectionDAG] Fix calling convention in expansion of ?MULO. from to [SelectionDAG] Fix calling convention in expansion of ?MULO..
Oct 3 2016, 8:59 PM
whitequark added a comment to D22736: Make LLVMInitializeAll* API have their symbols.

@nagisa ping?

Oct 3 2016, 8:50 PM

Sep 30 2016

whitequark accepted D25128: [OCaml] Install .mli (interface) files.

LGTM

Sep 30 2016, 2:08 PM
whitequark accepted D24354: cmake: Install the OCaml libraries into a more correct path.

LGTM

Sep 30 2016, 10:41 AM

Sep 20 2016

whitequark added inline comments to D24354: cmake: Install the OCaml libraries into a more correct path.
Sep 20 2016, 12:15 PM
whitequark added a comment to D24354: cmake: Install the OCaml libraries into a more correct path.

@jpdeplaix can you please test the updated patch also?

Sep 20 2016, 6:34 AM

Sep 9 2016

whitequark added a comment to D24354: cmake: Install the OCaml libraries into a more correct path.

@jpdeplaix Can you please also test the changes? Once I get ACK from you I will commit.

Sep 9 2016, 3:35 AM
whitequark added inline comments to D24354: cmake: Install the OCaml libraries into a more correct path.
Sep 9 2016, 3:19 AM

Sep 8 2016

whitequark added a comment to D24355: cmake: Make OCaml library install path configurable.

I don't see any point in having them separately in git either, it is just confusing since you are making logically one change to one component...

Sep 8 2016, 11:06 AM
whitequark added a comment to D24355: cmake: Make OCaml library install path configurable.

Please just fold these three patches into one.

Sep 8 2016, 10:43 AM
whitequark added a comment to D24354: cmake: Install the OCaml libraries into a more correct path.

But doesn't OCAML_STDLIB_PATH include /usr? So you would be installing to /usr/local/usr/lib/ocaml with the default config, unless I'm missing something.

Sep 8 2016, 10:42 AM

Sep 5 2016

whitequark committed rL280667: CODE_OWNERS: bring my entry up to date.
CODE_OWNERS: bring my entry up to date
Sep 5 2016, 10:51 AM

Sep 4 2016

whitequark committed rL280642: [CMake] [OCaml] Allow building OCaml bindings out of tree..
[CMake] [OCaml] Allow building OCaml bindings out of tree.
Sep 4 2016, 6:50 PM

Aug 30 2016

whitequark added a comment to D22736: Make LLVMInitializeAll* API have their symbols.

@nagisa, please test your changes on Windows and OS X. (For reference the commit that introduced it can be seen at rL192690 and the revert at rL192697.)

Aug 30 2016, 9:52 AM
whitequark added a comment to D9653: [PATCH 1/2] Add a "probe-stack" attribute.

@majnemer ping? I am also interested in this.

Aug 30 2016, 5:14 AM
whitequark committed rL280071: docs: mention that clobbering output regs in inline asm is illegal..
docs: mention that clobbering output regs in inline asm is illegal.
Aug 30 2016, 3:57 AM

Aug 23 2016

whitequark closed D23763: cmake: Add LLVM_ENABLE_OCAMLDOC to control building OCaml bindings doc.

rL279544

Aug 23 2016, 11:15 AM
whitequark committed rL279544: [CMake] [OCaml] Add -DLLVM_ENABLE_OCAMLDOC switch.
[CMake] [OCaml] Add -DLLVM_ENABLE_OCAMLDOC switch
Aug 23 2016, 11:15 AM

Aug 22 2016

whitequark accepted D23763: cmake: Add LLVM_ENABLE_OCAMLDOC to control building OCaml bindings doc.

LGTM

Aug 22 2016, 7:27 AM

Jul 24 2016

whitequark added a reviewer for D22736: Make LLVMInitializeAll* API have their symbols: echristo.

@echristo Assuming this works as one would expect, this is a massive improvement. However, I'm not completely certain of all subtle build system behavior. Do you see any potential downsides?

Jul 24 2016, 8:48 AM
whitequark added a comment to D22734: Make LLVMInitializeAll* API have their symbols.

@nagisa, yes, I think that will work.

Jul 24 2016, 2:41 AM
whitequark requested changes to D22734: Make LLVMInitializeAll* API have their symbols.

@nagisa, they are deliberately inline and deliberately unavailable for FFI use. After your change, every single executable statically linking to Target will link every individual backend, which makes them at least 200-500MB larger and increases link times by 10-60s (ballpark numbers).

Jul 24 2016, 2:10 AM

Jul 20 2016

whitequark added a comment to D21265: Expose AttributeSetNode, use it to provide aggregate getter for attribute in the C API..

@deadalnix, So, no aggregate getters at all? That's unacceptable.

Jul 20 2016, 10:06 PM

Jun 21 2016

whitequark committed rL273370: [OCaml] Add functions for accessing metadata nodes..
[OCaml] Add functions for accessing metadata nodes.
Jun 21 2016, 8:37 PM
whitequark closed D19309: OCaml bindings: Add functions for accessing metadata nodes by committing rL273370: [OCaml] Add functions for accessing metadata nodes..
Jun 21 2016, 8:37 PM
whitequark accepted D19309: OCaml bindings: Add functions for accessing metadata nodes.

LGTM

Jun 21 2016, 2:45 AM

Jun 15 2016

whitequark accepted D21365: Add support for string attributes in the C API..

LGTM

Jun 15 2016, 7:45 AM

Jun 14 2016

whitequark accepted D21266: Add support for callsite in the new C API for attributes.

LGTM

Jun 14 2016, 7:51 PM

Jun 13 2016

whitequark added a comment to D21316: Remove the ScalarReplAggregates pass.

This is great!

Jun 13 2016, 5:17 PM

Jun 11 2016

whitequark accepted D19181: Map Attribute in the C API..
Jun 11 2016, 10:32 PM
whitequark accepted D21265: Expose AttributeSetNode, use it to provide aggregate getter for attribute in the C API..

Aggregate getters LGTM

Jun 11 2016, 8:51 PM
whitequark added a comment to D19181: Map Attribute in the C API..

As per IRC discussion, some renaming

Jun 11 2016, 6:13 PM
whitequark added inline comments to D19181: Map Attribute in the C API..
Jun 11 2016, 5:40 PM
whitequark added inline comments to D19181: Map Attribute in the C API..
Jun 11 2016, 5:26 PM
whitequark requested changes to D19181: Map Attribute in the C API..
Jun 11 2016, 5:13 PM
whitequark added inline comments to D19181: Map Attribute in the C API..
Jun 11 2016, 5:13 PM

May 23 2016

whitequark accepted D20417: Extract renaming from D19181.

LGTM.

May 23 2016, 5:43 AM

May 10 2016

whitequark accepted D19828: [OCaml] Update core test and re-enable testing.

LGTM

May 10 2016, 4:16 AM

May 3 2016

whitequark added inline comments to D19828: [OCaml] Update core test and re-enable testing.
May 3 2016, 2:08 AM

Apr 27 2016

whitequark added a comment to D19181: Map Attribute in the C API..

Why do you say adding a single attribute is the most common use-case? I'd expect the most common use to be to be creating a function definition/declaration/call instruction from scratch, with a given set of specified function/parameter/return-value attributes. Which is ideally suited for constructing an attribute set, and then calling a setter to place it onto the instruction. Why do you think RMW operations would be primary?

Apr 27 2016, 8:30 PM
whitequark added a comment to D19181: Map Attribute in the C API..

@jyknight I strongly dislike exposing AttributeSet. What is the proposed usecase? FFI calls are expensive and using AttributeSet requires at least three operations (RMW) instead of one (Add) for the most common case (adding a single attribute). Further, AttributeSet is not easily interrogated; to get the full list of attributes, I propose (in the future) to add a function that returns an array of LLVMAttributeRef, which is again much nicer to bindings.

Apr 27 2016, 5:36 AM

Apr 26 2016

whitequark added a comment to D19181: Map Attribute in the C API..

I have no more objections.

Apr 26 2016, 5:51 PM
whitequark added inline comments to D19181: Map Attribute in the C API..
Apr 26 2016, 5:48 PM
whitequark added a comment to D19181: Map Attribute in the C API..

One thing I would like to have right away is a way to get the kind of an attribute. Looks good otherwise.

Apr 26 2016, 5:36 PM
whitequark requested changes to D19309: OCaml bindings: Add functions for accessing metadata nodes.
Apr 26 2016, 11:38 AM

Apr 25 2016

whitequark accepted D19309: OCaml bindings: Add functions for accessing metadata nodes.

LGTM, but please commit once you are certain that tests are pass.

Apr 25 2016, 11:18 AM

Apr 19 2016

whitequark added inline comments to D19309: OCaml bindings: Add functions for accessing metadata nodes.
Apr 19 2016, 11:10 PM

Apr 14 2016

whitequark added a comment to D19081: Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration away from LLVMAttribute.

Will target dependent attributes be covered by the API (like "no-sse")? Or is it only the regular attributes?

Apr 14 2016, 8:38 AM

Apr 13 2016

whitequark added a comment to D18749: Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration away from LLVMAttribute.

@rafael The C enum doesn't help much since frontends using libffi to bind to the C API have to duplicate the enum in the binding. Whereas, the function will work for at least removed attributes (it can return 0 and signal an error to the frontend).

Apr 13 2016, 3:51 PM
whitequark added a comment to D19037: [llvm-c] Add the ability to create debug locations.

@echristo What about exposing the bare key-value metadata interface? It itself can be stable, and frontends could use it before anything more specific is stabilized.

Apr 13 2016, 2:54 PM
whitequark added inline comments to D19037: [llvm-c] Add the ability to create debug locations.
Apr 13 2016, 2:48 PM
whitequark added a comment to D18749: Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration away from LLVMAttribute.

@rafael I don't understand. How are you proposing frontends using LLVM-C emit functions with attributes?

Apr 13 2016, 1:48 PM
whitequark accepted D18749: Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration away from LLVMAttribute.

LGTM. I agree with @Wallbraker that the functions accepting AttrKindIDs will have to have their ABI versions bumped.

Apr 13 2016, 8:45 AM

Apr 10 2016

whitequark added a comment to D18891: [OCaml] Expose the LLVM diagnostic handler.

Yes, please remove those parts and re-enable the tests.

Apr 10 2016, 6:32 AM
whitequark accepted D18891: [OCaml] Expose the LLVM diagnostic handler.

LGTM, thanks!

Apr 10 2016, 6:25 AM
whitequark added inline comments to D18891: [OCaml] Expose the LLVM diagnostic handler.
Apr 10 2016, 5:45 AM

Apr 8 2016

whitequark added inline comments to D18891: [OCaml] Expose the LLVM diagnostic handler.
Apr 8 2016, 3:00 AM
whitequark added inline comments to D18891: [OCaml] Expose the LLVM diagnostic handler.
Apr 8 2016, 2:45 AM
whitequark accepted D18820: [llvm-c] Expose LLVMContextGetDiagnostic{Handler,Context}.
Apr 8 2016, 2:07 AM

Apr 6 2016

whitequark added a reviewer for D18820: [llvm-c] Expose LLVMContextGetDiagnostic{Handler,Context}: deadalnix.

deadalnix, does the test look OK to you?

Apr 6 2016, 4:38 PM
whitequark requested changes to D18820: [llvm-c] Expose LLVMContextGetDiagnostic{Handler,Context}.

Actually, can you please add a test? The main function of llvm-c-test/echo.cpp seems to be a suitable place to set and then retrieve a diagnostic handler.

Apr 6 2016, 3:31 PM
whitequark committed rL265608: [llvm-c] Add LLVMGetValueKind..
[llvm-c] Add LLVMGetValueKind.
Apr 6 2016, 3:27 PM
whitequark closed D18729: [llvm-c] Improve IR Introspection: Add ValueKind by committing rL265608: [llvm-c] Add LLVMGetValueKind..
Apr 6 2016, 3:26 PM
whitequark accepted D18820: [llvm-c] Expose LLVMContextGetDiagnostic{Handler,Context}.

LGTM

Apr 6 2016, 2:48 PM

Apr 5 2016

whitequark committed rL265394: [llvm-c] Expose LLVM{Get,Set}ModuleIdentifier.
[llvm-c] Expose LLVM{Get,Set}ModuleIdentifier
Apr 5 2016, 7:02 AM
whitequark closed D18736: [llvm-c] Improve IR Introspection: Add LLVM{Get,Set}ModuleIdentifier by committing rL265394: [llvm-c] Expose LLVM{Get,Set}ModuleIdentifier.
Apr 5 2016, 7:02 AM

Apr 4 2016

whitequark added inline comments to D18736: [llvm-c] Improve IR Introspection: Add LLVM{Get,Set}ModuleIdentifier.
Apr 4 2016, 12:58 PM
whitequark accepted D18729: [llvm-c] Improve IR Introspection: Add ValueKind.

LGTM.

Apr 4 2016, 12:44 PM
whitequark accepted D18736: [llvm-c] Improve IR Introspection: Add LLVM{Get,Set}ModuleIdentifier.
Apr 4 2016, 10:31 AM
whitequark added inline comments to D18749: Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration away from LLVMAttribute.
Apr 4 2016, 12:21 AM
whitequark added inline comments to D18749: Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration away from LLVMAttribute.
Apr 4 2016, 12:14 AM

Apr 3 2016

whitequark added inline comments to D18749: Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration away from LLVMAttribute.
Apr 3 2016, 11:12 PM
whitequark added a comment to D18729: [llvm-c] Improve IR Introspection: Add ValueKind.

The reason the table exists is for bindings. Without LLVMGetValueKind(), a binding that wishes to introspect an instruction has to call the multitude of LLVMIsA* functions in sequence, which is:

  1. Slow (many bindings use libffi)
  2. Usually cannot be inlined (see 1)
  3. Fragile and hostile to upgrades of LLVM, as there isn't even an easy way to figure out the type of the value that broke the check
Apr 3 2016, 3:09 PM