Skip to content

[AST] NFC: Repack misc AnyFunctionType bits #13395

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Dec 13, 2017
Merged

[AST] NFC: Repack misc AnyFunctionType bits #13395

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b301d74
[AST] NFC: Repack misc AnyFunctionType bits
davezarzycki Dec 12, 2017
4a28744
[AST] NFC: Assert that params are not dropped
davezarzycki Dec 12, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions include/swift/AST/Types.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -301,8 +301,10 @@ class alignas(1 << TypeAlignInBits) TypeBase {
/// regparm and the calling convention.
enum { NumExtInfoBits = 7 };
unsigned ExtInfo : NumExtInfoBits;

unsigned NumParams : 10;
};
NUMBITS(AnyFunctionType, NumTypeBaseBits + 7);
NUMBITS(AnyFunctionType, NumTypeBaseBits + 17);

struct ArchetypeTypeBitfields {
unsigned : NumTypeBaseBits;
Expand Down Expand Up @@ -2397,7 +2399,6 @@ getSILFunctionLanguage(SILFunctionTypeRepresentation rep) {
class AnyFunctionType : public TypeBase {
const Type Input;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we store the parameters directly why do we store the input type as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a good question. I imagine that in practice that const Type Input is effectively a cache. In any case, that is beyond the scope of this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mea culpa: Haven't finished migrating clients away from the old representation. We shunt back and forth between the two still - would require more work than just one or two PRs to switch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I've been poking around this area. @CodaFi – Where in your priority list is eliminating getInput()?

Copy link
Contributor

@CodaFi CodaFi Dec 13, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somewhere at or below eliminating InOutType. That's a much more feasible goal than re-formulating the way the type checker looks at paren types at the moment

const Type Output;
const unsigned NumParams;

public:
using Representation = FunctionTypeRepresentation;
Expand Down Expand Up @@ -2609,9 +2610,10 @@ class AnyFunctionType : public TypeBase {
AnyFunctionType(TypeKind Kind, const ASTContext *CanTypeContext,
Type Input, Type Output, RecursiveTypeProperties properties,
unsigned NumParams, const ExtInfo &Info)
: TypeBase(Kind, CanTypeContext, properties), Input(Input), Output(Output),
NumParams(NumParams) {
: TypeBase(Kind, CanTypeContext, properties), Input(Input), Output(Output) {
AnyFunctionTypeBits.ExtInfo = Info.Bits;
AnyFunctionTypeBits.NumParams = NumParams;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add an assertion that this hasn't dropped information? (in case someone actually has 1024 parameters)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I figured that about 1000 parameters was about 100 times more than any reasonable programmer would need/want. :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, for sure, but code generators aren't reasonable programmers. (Clearly I don't really care at this time, though, or I'd ask for something stronger than an assertion.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ya, code generators are a pain. They can easily exceed otherwise reasonable compile time limits. That being said, I think adding runtime errors when compile time limits are exceeded is a separable goal.

assert(AnyFunctionTypeBits.NumParams == NumParams && "Params dropped!");
// The use of both assert() and static_assert() is intentional.
assert(AnyFunctionTypeBits.ExtInfo == Info.Bits && "Bits were dropped!");
static_assert(ExtInfo::NumMaskBits ==
Expand All @@ -2638,7 +2640,7 @@ class AnyFunctionType : public TypeBase {
Type getInput() const { return Input; }
Type getResult() const { return Output; }
ArrayRef<AnyFunctionType::Param> getParams() const;
unsigned getNumParams() const { return NumParams; }
unsigned getNumParams() const { return AnyFunctionTypeBits.NumParams; }

GenericSignature *getOptGenericSignature() const;

Expand Down