angerman (Moritz Angermann)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

User Since
Sep 11 2014, 7:17 AM (145 w, 5 d)
Availability
Available

Recent Activity

Fri, Jun 16

angerman added a comment to D3647: Introduce module hierarchy.

As we use the textual IR for LLVM that should be explicit in the. Naming as well. IR.LLVM.Textual. I have the Data.Bitcode packages which I hope to eventually bring into GHC (it's just not high priority right now) and they would live in IR.LLVM.Bitcode with the proposed outline.

Fri, Jun 16, 9:00 AM

Thu, Jun 8

angerman added a comment to D3608: Extend the Quasi Monad.

There are still things to be done here.

Thu, Jun 8, 2:28 PM

Tue, Jun 6

angerman updated the diff for D3579: Drop special handling of iOS and Android.
  • Always allow -staticlib
Tue, Jun 6, 10:20 AM
angerman updated the diff for D3608: Extend the Quasi Monad.
  • Add AppendFile
  • Adds removeFile
Tue, Jun 6, 10:18 AM

Wed, May 31

angerman added a comment to D3352: Clean up opt and llc.

I agree, PIC is not free and we shouldn't assume that the user needs it. I'm curious to know why this was necessary.

Wed, May 31, 10:47 AM
angerman planned changes to D3352: Clean up opt and llc.
Wed, May 31, 8:54 AM
angerman added a comment to D3352: Clean up opt and llc.

We should not just force PIC on all LLVM users.

Wed, May 31, 8:54 AM

Tue, May 30

angerman updated subscribers of D3579: Drop special handling of iOS and Android.
Tue, May 30, 9:00 PM
angerman updated subscribers of D3617: Check target libtool.
Tue, May 30, 8:59 PM
angerman updated the diff for D3617: Check target libtool.
  • no special windows handling
Tue, May 30, 8:33 PM
angerman updated the diff for D3352: Clean up opt and llc.
  • always PIC
Tue, May 30, 8:26 PM
angerman added inline comments to D3617: Check target libtool.
Tue, May 30, 3:11 AM

Mon, May 29

angerman updated the diff for D3352: Clean up opt and llc.
  • drop mtriple and data-layout, as they are now hardcoded in the ir file.
  • bring back rmodel.
Mon, May 29, 9:18 PM
angerman updated the diff for D3352: Clean up opt and llc.
  • minor adjustments, validation pending.
Mon, May 29, 8:23 AM
angerman updated the diff for D3608: Extend the Quasi Monad.
  • rebase
Mon, May 29, 8:20 AM
Herald added a reviewer for D3617: Check target libtool: austin.
Mon, May 29, 8:18 AM
angerman added a comment to D3352: Clean up opt and llc.

Just to add to that. I'm really keen in figuring out what is going wrong here, I believe it's something with -fPIC and some small memory model llvm infers.

Mon, May 29, 5:37 AM
angerman added a comment to D3352: Clean up opt and llc.
In D3352#102743, @kavon wrote:

Something in our opt -> llc -> mangler -> as pipeline results in bad relocations being generated on aarch64.

If the bug isn't caused by this patch, we should create a new phab review for it.

Mon, May 29, 5:36 AM

Sun, May 28

angerman planned changes to D3352: Clean up opt and llc.

Something in our opt -> llc -> mangler -> as pipeline results in bad relocations being generated on aarch64.

Sun, May 28, 7:09 PM

May 27 2017

angerman updated the diff for D3608: Extend the Quasi Monad.
  • add time accessors
May 27 2017, 2:08 AM

May 25 2017

angerman updated the diff for D3601: [iserv] move forkIO.
  • rebase
May 25 2017, 3:57 AM
angerman updated the diff for D3608: Extend the Quasi Monad.
  • rebase
May 25 2017, 3:56 AM
angerman updated the diff for D3443: [iserv] Fixing the word size for RemotePtr and toWordArray.
  • rebase
May 25 2017, 3:55 AM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • rebase
May 25 2017, 3:54 AM
angerman updated the diff for D3579: Drop special handling of iOS and Android.
  • rebase
May 25 2017, 3:54 AM
angerman updated the diff for D3352: Clean up opt and llc.
  • rebase
May 25 2017, 3:52 AM

May 24 2017

angerman added a comment to D3608: Extend the Quasi Monad.

Well, either path towards short-term cross-compiler support for TH is going to involve some unsightly hacks, and I suppose this is at least a manageable hack. All I can do is grumble from the sidelines until we have proper multi-target awareness in GHC ;)

Just to be clear, here, I'm not a big fan of blowing up Quasi either. This however seems to be the least worst option. I've come to find a certain benefit in being explicit in the qAction though, as it provides more information to ghc about the actual intent.

May 24 2017, 10:21 AM
angerman added a comment to D3608: Extend the Quasi Monad.

Depending on what kind of IO we do, we might be fine. (if the IO doesn't touch processes or files, I do not (yet) see any issue with that kind of IO). When running ghc with -fexternal-interpreter the qXXX are evaluated in GHCiQ (see libraries/ghci/GHCi/TH.hs). Which running on the host has the capability to query the ghc instance on the build machine.

Hm, OK. I'm still a bit unclear where in libraries/ghci/GHCi/TH.hs this decision to query the build machine instead of the host one takes place, but I'll trust your word on this matter.

More importantly, I find the prospect of cramming a bunch of (fairly ad hoc) file/process IO operations into Quasi to be very unsettling. I know that Quasi is already a grab bag of assorted things, but this increases the API surface area by an extraordinary amount. Moreover, there doesn't appear to be any end in sight: what happens when a user needs even more operations from the directory/process library in Template Haskell? They'd either need to add even more Quasi class methods, or they'd need to completely reimplement their desired functions from scratch, but using Q operations instead of IO ones. Neither approach is very satisfying.

Instead, why not have functionality to toggle which machine to search for files on?

qWithMachine :: BuildOrHost -> Q a -> Q a

(API subject to bikeshedding.) That way, you can continue to use qRunIO as before for anything that queries files or processes, and you won't need to have a Quasi counterpart to every basic file/process op under the sun.

May 24 2017, 8:59 AM
angerman added a comment to D3608: Extend the Quasi Monad.

Thank you for the detailed explanation. But I'm not clearer than before on my second question: why are the file/process opesrtions you just added not subject to the same issues that qRunIO has? After all, they're also IO operations. Where specifically in the GHC codebase does a cross compiler make the decision to, e.g., look up executables on the build machine instead of the host machine when running qFindExecutables?

May 24 2017, 8:23 AM
angerman added a comment to D3608: Extend the Quasi Monad.

My apologies for not being familiar with the previous work on this front, but I don't see why this is necessary. Why does adding a bunch of hardcoded IO operations to Quasi resolve this issue, but qRunIO alone does not? Where in the code are cross compilers making the distinction between files on the build machine and files on the host machine when running, e.g., qFindExecutables?

May 24 2017, 7:58 AM
angerman updated the diff for D3608: Extend the Quasi Monad.
  • fix stat
May 24 2017, 3:58 AM
angerman updated the diff for D3608: Extend the Quasi Monad.
  • bump stat
May 24 2017, 3:14 AM
angerman updated the diff for D3608: Extend the Quasi Monad.
  • Fix validation.
May 24 2017, 2:29 AM

May 23 2017

angerman updated subscribers of D3443: [iserv] Fixing the word size for RemotePtr and toWordArray.
May 23 2017, 10:53 PM
angerman updated subscribers of D3448: [linker] fix armv7 & add aarch64.
May 23 2017, 10:52 PM
angerman abandoned D3502: Support `embedFile` in iserv slave.

As @simonmar suggested, extending the Quasi class is a much better solution. It also turns
the blackbox runIO into a more declarative version, where one could even opt to disallow
some functionality, and only allow others (from a security perspective).

May 23 2017, 10:52 PM
angerman updated subscribers of D3601: [iserv] move forkIO.
May 23 2017, 10:49 PM
angerman updated subscribers of D3352: Clean up opt and llc.
May 23 2017, 10:49 PM
angerman updated subscribers of D3608: Extend the Quasi Monad.
May 23 2017, 10:48 PM
angerman updated the diff for D3608: Extend the Quasi Monad.
  • bump TH deps.
May 23 2017, 10:38 PM
angerman created D3608: Extend the Quasi Monad.
May 23 2017, 9:45 PM
angerman added a comment to D3448: [linker] fix armv7 & add aarch64.

@bgamari, @simonmar is this good to go now?

May 23 2017, 7:45 PM
angerman updated the diff for D3352: Clean up opt and llc.
  • Cleanup
May 23 2017, 1:01 AM
angerman added inline comments to D3352: Clean up opt and llc.
May 23 2017, 1:01 AM

May 22 2017

angerman updated the diff for D3352: Clean up opt and llc.
  • bump allocation stat
May 22 2017, 11:30 PM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • cleanup
May 22 2017, 8:22 AM
angerman updated the diff for D3601: [iserv] move forkIO.
  • Adds docstring.
May 22 2017, 8:18 AM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • fix camelCase
May 22 2017, 7:32 AM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • camelCase all the things.
May 22 2017, 5:52 AM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • fix compilation warnings
May 22 2017, 1:19 AM
angerman updated the diff for D3502: Support `embedFile` in iserv slave.
  • rebase
May 22 2017, 12:28 AM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • rebase
May 22 2017, 12:26 AM
angerman updated the diff for D3443: [iserv] Fixing the word size for RemotePtr and toWordArray.
  • rebase
May 22 2017, 12:25 AM
angerman updated the diff for D3352: Clean up opt and llc.
  • rebase
May 22 2017, 12:23 AM
angerman created D3601: [iserv] move forkIO.
May 22 2017, 12:22 AM
angerman updated the diff for D3579: Drop special handling of iOS and Android.
  • rebase
May 22 2017, 12:17 AM

May 21 2017

angerman updated the diff for D3352: Clean up opt and llc.
  • Add llvm-targets
May 21 2017, 8:53 AM
angerman updated the diff for D3352: Clean up opt and llc.
  • When a GNU eats an Apple
May 21 2017, 5:41 AM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • fix signature
May 21 2017, 4:06 AM
angerman updated the diff for D3352: Clean up opt and llc.
  • fix comment.
May 21 2017, 3:22 AM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • fix up
May 21 2017, 3:17 AM
angerman updated the diff for D3352: Clean up opt and llc.
  • Fix dfeaultDynFlags
  • move gen-data-layout.sh
May 21 2017, 12:42 AM
angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • No SYMBOL EXTRAS for arm.
May 21 2017, 12:38 AM

May 20 2017

angerman updated the diff for D3352: Clean up opt and llc.
  • Comments + Cleanup
May 20 2017, 1:17 AM
angerman added a comment to D3352: Clean up opt and llc.

@kavon is this agreeable to you now?

May 20 2017, 12:33 AM
angerman updated the diff for D3579: Drop special handling of iOS and Android.
  • cleanup
May 20 2017, 12:27 AM
angerman updated the diff for D3352: Clean up opt and llc.
  • cleanup
May 20 2017, 12:25 AM

May 19 2017

angerman added a comment to D3352: Clean up opt and llc.
In D3352#102254, @kavon wrote:
In D3352#102253, @kavon wrote:

And passing this via -default-data-layout= to opt?

Sure, though I think the flag is is actually -data-layout=<layout-string>

Actually, with llvm 4. seemingly it's

opt --version
LLVM (http://llvm.org/):
  LLVM version 4.0.0
  Optimized build.
  Default target: x86_64-apple-darwin16.5.0
  Host CPU: skylake
May 19 2017, 10:03 AM
angerman added a comment to D3352: Clean up opt and llc.
In D3352#102234, @kavon wrote:

@angerman As far as I know, opt will not choose an appropriate datalayout for the given target triple... instead it will fall back on defaults that do not take the target into consideration [1]:

When constructing the data layout for a given target, LLVM starts with a default set of specifications which are then (possibly) overridden by the specifications in the datalayout keyword. The default specifications are given in this list:

This mismatch could lead to mis-optimizations of pointer arithmetic, for example. Until we're certain that this is not an issue, I would rather see the datalayout explicitly provided, at least when using opt.

[1] http://llvm.org/docs/LangRef.html#langref-datalayout

May 19 2017, 7:35 AM
angerman updated the diff for D3352: Clean up opt and llc.
  • Revert "Int -> Word"
May 19 2017, 12:50 AM

May 18 2017

angerman updated subscribers of D3352: Clean up opt and llc.

One question I have about this is why we need to know about clang at all? Can't we generally just call the "normal" C compiler, regardless of whether than happens to be gcc or clang.

May 18 2017, 10:32 PM
angerman updated the summary of D3352: Clean up opt and llc.
May 18 2017, 9:23 PM
angerman updated the summary of D3352: Clean up opt and llc.
May 18 2017, 9:21 PM
angerman added inline comments to D3352: Clean up opt and llc.
May 18 2017, 9:13 PM
angerman updated the diff for D3352: Clean up opt and llc.
  • Add ticket number.
May 18 2017, 8:59 PM
angerman updated the diff for D3352: Clean up opt and llc.
  • non-negative optLevel and case
May 18 2017, 7:49 PM
angerman accepted D3597: Improve error msg for simplifier tick exhaustion.

Looks fine to me. Assuming the (unrelated) macOS build failure will be gone with a rebase.

May 18 2017, 7:27 PM
angerman added inline comments to D3352: Clean up opt and llc.
May 18 2017, 7:07 PM
angerman added inline comments to D3352: Clean up opt and llc.
May 18 2017, 9:20 AM
angerman added a comment to D3352: Clean up opt and llc.

I'll see to opening tickets tomorrow.

May 18 2017, 9:19 AM
angerman updated the diff for D3352: Clean up opt and llc.
  • Cleanup.
  • Embed crashlog
May 18 2017, 9:18 AM

May 17 2017

angerman added inline comments to D3352: Clean up opt and llc.
May 17 2017, 9:39 PM

May 16 2017

Herald added a reviewer for D3591: Bump to LLVM 4.0: austin.
May 16 2017, 12:13 AM

May 15 2017

angerman abandoned D3574: Add libffi via submodule.
May 15 2017, 7:51 PM
angerman added a comment to D3574: Add libffi via submodule.

Why do we ship libffi in the first place?

May 15 2017, 7:25 PM
angerman added a comment to D3574: Add libffi via submodule.

If we are willing to add that dependency, we could probably kill off the following code in aclocal.m4 as well, and replace it with the LT check

# FP_LEADING_UNDERSCORE
# ---------------------
# Test for determining whether symbol names have a leading underscore. We assume
# that they _haven't_ if anything goes wrong. Sets the output variable
# LeadingUnderscore to YES or NO and defines LEADING_UNDERSCORE correspondingly.
#
# Some nlist implementations seem to try to be compatible by ignoring a leading
# underscore sometimes (eg. FreeBSD). We therefore have to work around this by
# checking for *no* leading underscore first. Sigh.  --SDM
#
# Similarly on OpenBSD, but this test doesn't help. -- dons
#
AC_DEFUN([FP_LEADING_UNDERSCORE],
[AC_CHECK_LIB([elf], [nlist], [LIBS="-lelf $LIBS"])
AC_CACHE_CHECK([leading underscore in symbol names], [fptools_cv_leading_underscore], [
# Hack!: nlist() under Digital UNIX insist on there being an _,
# but symbol table listings shows none. What is going on here?!?
case $TargetPlatform in
    # Apples mach-o platforms use leading underscores
    *-apple-*) fptools_cv_leading_underscore=yes;;
    *linux-android*) fptools_cv_leading_underscore=no;;
    *openbsd*) # x86 openbsd is ELF from 3.4 >, meaning no leading uscore
      case $build in
        i386-*2\.@<:@0-9@:>@ | i386-*3\.@<:@0-3@:>@ ) fptools_cv_leading_underscore=yes ;;
        *) fptools_cv_leading_underscore=no ;;
      esac ;;
    i386-unknown-mingw32) fptools_cv_leading_underscore=yes;;
    x86_64-unknown-mingw32) fptools_cv_leading_underscore=no;;
    *) AC_RUN_IFELSE([AC_LANG_SOURCE([[#ifdef HAVE_NLIST_H
#include <nlist.h>
struct nlist xYzzY1[] = {{"xYzzY1", 0},{0}};
struct nlist xYzzY2[] = {{"_xYzzY2", 0},{0}};
#endif
May 15 2017, 9:46 AM
angerman added a comment to D3574: Add libffi via submodule.

So when libffi eventually does have a new release will we still need the new dependency libtldl-dev to build GHC?

May 15 2017, 9:46 AM
angerman added a comment to D3574: Add libffi via submodule.

That's helpful but wasn't what I wanted to know about. What's this stuff about libtool?

May 15 2017, 9:46 AM
angerman added a comment to D3574: Add libffi via submodule.

I hear something about a new dependency. What is it and why is it needed?

May 15 2017, 9:18 AM
angerman added a comment to D3502: Support `embedFile` in iserv slave.

We don't have a good way to virtualize the file system (or IO in general). My concern is that whatever mechanisms we put in place here won't be enough.

I too, share that fear.

May 15 2017, 5:19 AM

May 14 2017

angerman updated the diff for D3448: [linker] fix armv7 & add aarch64.
  • rebase
May 14 2017, 10:12 PM
angerman updated the diff for D3502: Support `embedFile` in iserv slave.
  • rebase
May 14 2017, 10:11 PM
angerman updated the diff for D3443: [iserv] Fixing the word size for RemotePtr and toWordArray.
  • rebase
May 14 2017, 10:10 PM
angerman updated the diff for D3574: Add libffi via submodule.
  • Drop CI debug
  • rebase
May 14 2017, 10:09 PM
angerman updated the diff for D3579: Drop special handling of iOS and Android.
  • rebase
May 14 2017, 10:06 PM
angerman updated the diff for D3352: Clean up opt and llc.
  • rebase
May 14 2017, 10:05 PM
angerman added a comment to D3574: Add libffi via submodule.
dpkg -l '*libtool*'
dpkg -l '*libltdl*'

results in

May 14 2017, 9:37 PM
angerman updated the diff for D3574: Add libffi via submodule.
  • :(((
May 14 2017, 8:53 PM
angerman updated the diff for D3574: Add libffi via submodule.
  • :((
May 14 2017, 8:22 PM
angerman updated the diff for D3574: Add libffi via submodule.
  • :(
May 14 2017, 8:04 PM