Finding pointer width from target triple during AST parsing

Development Compiler
1

I think this is a simple question? I'm just a bit too new to swift/LLVM to know where to look.

I want to create a patch for this code in include/swift/AST/Types.h...

  /// Get the least supported value for the width.
  ///
  /// FIXME: This should be build-configuration-dependent.
  unsigned getLeastWidth() const {
    if (isFixedWidth())
      return getFixedWidth();
    if (isPointerWidth())
      return 32;
    llvm_unreachable("impossible width value");
  }
  
  /// Get the greatest supported value for the width.
  ///
  /// FIXME: This should be build-configuration-dependent.
  unsigned getGreatestWidth() const {
    if (isFixedWidth())
      return getFixedWidth();
    if (isPointerWidth())
      return 64;
    llvm_unreachable("impossible width value");
  }

I want to return the actual pointer width instead of the hard coded values 32/64.

In IRGen, I've seen something like this:

IRGenFunction &IGF
auto *size = FixedTypeInfo::getStaticSize(IGF.IGM);
unsigned pointerWidth = size->getType()->getScalarSizeInBits();

But that context isn't going to be available during AST (and nor should it really because SIL is supposed to be platform agnostic).

Can anyone advise how I might access the pointer width at this early stage in compilation?

2

As a slightly nasty hack I could maybe use CMAKE_SIZEOF_VOID_P and, with my limited understanding of how CMake works, I think the build would automatically end up with the (void) pointer width copied into the build intermediates and compiled, but it still seems like a slightly fragile hack?

I'm thinking more of accessing something from llvm or (better) a swift wrapper around that?

3

CMAKE_SIZEOF_VOID_P would give you the size on the host system, not the target system.

It looks like llvm::Triple has APIs isArch{16,32,64}Bit. You could consider directly using those, or you could refactor that code in LLVM to expose the actual pointer width.

4

Yeah, I was concerned that CMAKE_SIZEOF_VOID_P would give host pointer size, although it is used inside the standard library so I sort of assumed CMake must be able to figure that out somehow correctly, otherwise you wouldn't be able to build cross compilers for things like 32 bit ARM (armv7) on macOS, which must be possible!

I was investigating llvm::Triple too. As I read the code, that would be available in the AST context?

That would probably do for my purposes for now. I'll create a patch for this as it seems something that might be worth submitting? How/where would I submit if appropriate? Should I fork and create a merge request on github? If so, should it reference this discussion somehow?

Carl

5

Yep, the current target triple is available in the LangOptions stored (well, referenced) from the ASTContext.

Fork + merge request is our usual contribution mechanism; linking to this discussion seems reasonable.

1 Like